[Q]signing an encrypting, integirty

Adrian 'Dagurashibanipal' von Bidder avbidder@fortytwo.ch
Wed Jul 9 19:23:02 2003

Content-Type: text/plain;
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.


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=
he's the author of the paper at=20
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html discussing this=20

The general consensus is: it's not a technical problem. There are two thing=
 - imagine a perfectly protected message M sent from Alice to Bob. Bob can =
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=
 - encryption does not imply any special meaning. Personally, I had problem=
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=
and/or context). Encryption adds security on a technical level to transport=
the message. If the recipient receives a message with confidential content=
unencrypted he should know that something weird is going on.

Don Davis' solution Sign/Encrypt/Sign or Encrypt/Sign/Encrypt (I prefer the=
former) is just a formalized way to certify that a message was intended to =
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=
(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
 - 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 =
msg was sent encrypted in the first place, or the sender gains something by=
being able to prove that the msg was sent encrypted in the first place. But=
I'm not exactly clear on what he gains: Let's assume the secret message lea=
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

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

Content-Type: application/pgp-signature
Content-Description: signature

Version: GnuPG v1.2.1 (GNU/Linux)

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.5&md5sum=5dff868d11843276071b25eb7006da3e