Deniability

[David Shaw]

On Mar 22, 2011, at 12:01 PM, Jerome Baum wrote:

> 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.

Hmm.  I'm not sure you and I are on the same page with this attack.  I don't think that Alice's rigged message to Baker necessarily needs to be forged to come from the original sender.  Alice can send the message to Baker as herself, with no special signing or other trickery to fool Baker about the origin of the message.  She can even sign it (as herself) if she wants.  The contents of the message just need to be something Baker would naturally reply to.

David