jerome at jeromebaum.com
Tue Mar 22 17:01:33 CET 2011
David Shaw <dshaw at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 880 bytes
Desc: not available
More information about the Gnupg-users