David Shaw <ds...@jabberwocky.com> writes: > On Mar 22, 2011, at 10:44 AM, Jerome Baum wrote: > >> Would that be by reusing the session key? Or are there other properties >> that we can mess with? > > Sorry, yes, that's re-using the session key (didn't mean to be > mysterious). Since Alice, as a recipient, can find the session key, > she can encrypt a new message to Baker with that session key, prefix > it with the unknown recipient's encrypted session key, and send the > whole message to Baker. If Baker can read it, then it reveals who the > unknown recipient is.
Is there anything that can be done to mitigate that attack? Obviously, we can't save a list of past session keys, I wouldn't even say we can save the hashes of past session keys (with their random data -- as _both_ are unlikely to appear ever again). Actually thinking about it myself, if the message turns out to be unsigned, and we agreed to _always_ sign our messages (even with just a throw-away key previously agreed on), then it would be a good tip-off and Baker wouldn't answer but instead alert me. How would you go about doing that? I can see three options: 1. Include a secret token -- any way to make GPG aware of this? Otherwise, prone to error. 2. Symmetrically encrypt the original message first, with a known key, and if asymmetric decryption yields an actual text, it's a tip-off. Pretty prone to error, and very tedious. 3. Sign the message using a real key. No deniability for sender. 4. Sign the message using a fake key. If you have the original message signing the fake key as being "okay", no deniability for sender. 5. Sign the message using a new fake key every time. Deniability for sender, and you just check whether the uid is correct. This is a bit like #1/secret token, but it would be more obvious when the token is missing (no signature). Still, a bit prone to error. Now, a those were either not deniable or prone to error. Looking at how OTR operates, IIRC it uses a MAC -- right? So just adapt #4 to yield: 6. Sign the message using a fake key that both parties have. The only other person with the "this key is okay" message is your correspondent, and they can't "tell on you" as they could have signed the message themselves. Any more problems with this method? -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
pgpd5XGWNuez9.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
