[Q]signing an encrypting, integirty

[Adrian 'Dagurashibanipal' von Bidder]

--Boundary-02=_l/ED/eX/e4PtFG0
Content-Type: text/plain;
  charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 09 July 2003 17:12, Lukasz Stelmach wrote:

> {{msg}a}B
>
> Alice sends, some secret data to Bob. Bob can decrypt message
> and crypt it for Charlie as if it has been sent by Alice:
>
> {{msg}a}C
>
> which in fact is not true. There is no way for charile to
> know that Bob has anything to do with the message.

Yo!

This has been discussed before at least on this mailing list and on the=20
ietf-openpgp working group mailing list. Search the archives for 'Don Davis=
',=20
he's the author of the paper at=20
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html discussing this=20
problem.

The general consensus is: it's not a technical problem. There are two thing=
s:
 - imagine a perfectly protected message M sent from Alice to Bob. Bob can =
=2D=20
and he doesn't need to hack anything - forward this message as his own to=20
Charlie. There's nothing anybody can do against this with technical measure=
s.
 - encryption does not imply any special meaning. Personally, I had problem=
s=20
with this at first, but I'm now convinced. If a message should be=20
confidential, it should say so in the message (or be clear from the content=
=20
and/or context). Encryption adds security on a technical level to transport=
=20
the message. If the recipient receives a message with confidential content=
=20
unencrypted he should know that something weird is going on.

Don Davis' solution Sign/Encrypt/Sign or Encrypt/Sign/Encrypt (I prefer the=
=20
former) is just a formalized way to certify that a message was intended to =
be=20
encrypted from the beginning. Personally, I don't think this matters much:
 - the sender wants his message to be confidential, so he'll send it encryp=
ted=20
(and he'll see that he sent it encrypted, there's no need to certify this).
 - the recipient can read the message anyway, so for him it's no big=20
difference
 - from an attacker's PoV, S/E/S provides additional information (in the=20
outmost signature), while E/S/E looks exactly like regular E/S

The counter argument is that the recipient gains something by knowing that =
the=20
msg was sent encrypted in the first place, or the sender gains something by=
=20
being able to prove that the msg was sent encrypted in the first place. But=
=20
I'm not exactly clear on what he gains: Let's assume the secret message lea=
ks=20
out. There's two scenarious:
 * Recipient accuses sender of leaking the secret. There's nothing to be=20
gained, the sender could have leaked the secret anyway.
 * Sender accuses recipient. This is the same, since the recipient could=20
decrypt the content

The case where the Recipient accuses the Sender of sending the secret=20
unencrypted is imho equivalent to the first case.

So long
=2D- vbi

=2D-=20
Available for key signing in Z=FCrich and Basel, Switzerland
                     (what's this? Look at http://fortytwo.ch/gpg/intro)

--Boundary-02=_l/ED/eX/e4PtFG0
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iKcEABECAGcFAj8MT+VgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWD5EAniMTDVqUzhgzOMEqNbNvYjAU
p8LHAJ48KsAS9FHyBPvyHdSgvuOs74DfCg==
=2HOg
-----END PGP SIGNATURE-----
Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.5&md5sum=5dff868d11843276071b25eb7006da3e

--Boundary-02=_l/ED/eX/e4PtFG0--