[OTR-users] The effectiveness of deniability

[Ximin Luo]

On 29/11/13 16:55, Daniel Kahn Gillmor wrote:
> 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
> 

Unfortunately I'm nowhere nearby, but would be interested in any materials you guys might release afterwards!

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

Yes, I understand and agree with this part. However, the usage of the English phrase "deniability", coupled with statements like "not even Bob can prove" is misleading, since human interactions (and courts) aren't always based on cryptographic proofs, often just "reasonable doubt". As I showed above, there are other non-cryptographic hints which strongly suggest non-deniability.

For security properties like confidentiality/authenticity this doesn't matter since they are positive qualities. However, deniability is a negative quality. In OTR's case, we are not "cryptographically denying a claim", instead we are "denying a cryptographic claim", which is not that strong at all.

I am hesitating even bringing it up in the next cryptoparty session I will do, because compared to the other properties, it's quite shaky, and might just confuse the audience when I talk about the many caveats like the ones above.

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

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

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