[OTR-users] The effectiveness of deniability

[Daniel Kahn Gillmor]

On 11/29/2013 11:19 AM, Ximin Luo wrote:
> However, I don't think this is a very realistic scenario - if an attacker can see a single OTR message, they very likely can see the original handshake anyway, which *is* linked (logistically, if not cryptographically from the POV of the attacker) to the long-term identity keys, breaking deniability.

if you're interested in the legal implications of these choices, and
you'll be near New York City on Monday, you might want to bring these
questions and observations to this messaging and deniability discussion:

  https://www.calyxinstitute.org/events/multiparty-otr-and-deniability

> If either party is going to collude with an attacker, then why would they obey protocol and discard the old keys?

My understanding for standard two-party OTR is that deniability arises
from the fact that both parties know the shared key.  so if one party
receives a message that validates against the derived MAC key that they
did not send, they know it came from the other party.  In the event that
your peer is collaborating with your adversary, your "deniability"
defense is "my peer also had access to the MAC key, and could have
generated that validated message themselves."  (note that this "it came
from someone who knew the key and i know it didn't come from me"
mechanism doesn't scale to multi-party OTR if you want to know who the
message sender is without being able to prove it cryptographically to a
third party).

the collaborating peer can cryptographically prove that they had a
conversation with you (because your long-term key signed a session key
they have access to), but they cannot (cryptographically) prove that you
wrote any particular message in that session.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20131129/450b088a/attachment.pgp>