Deniability

[Jerome Baum]

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
Type: application/pgp-signature
Size: 880 bytes
Desc: not available
URL: </pipermail/attachments/20110322/c1dffbd3/attachment.pgp>