[OTR-dev] Simplifying deniability

[Trevor Perrin]

On Wed, Jul 31, 2013 at 1:37 AM, Paul Wouters <paul at cypherpunks.ca> wrote:
> On Tue, 30 Jul 2013, Trevor Perrin wrote:
>
> [Note that I'm not a cryptographer, just a protocol implementer...]
>
>
>>> No. It simply means Alice got an automated reply from Bob's machine.
>>
>>
>> With what Moxie specified, a full transcript doesn't even mean that much.
>
>
> I don't understand this. Either Alice gets some kind of answer from Bob
> or his machine, or not. I don't see how the protocol implementation
> matters for this.


The difference is what Alice can prove to a 3rd party.

After communicating with Bob, Alice could present Bob's OTR signature
to convince a 3rd party of a number of things:

 - Alice has either directly performed OTR with Bob, or has received a
signature from someone who has.
 - Bob has performed OTR after some point in time (accomplished by
Alice encoding her DH private key as a hash of some timely data, such
as stock market prices).
 - A lower-bound on the number of OTR handshakes Bob has performed.

With an implicitly-authenticated key agreement ("triple-DH", MQV,
etc.), Alice can't prove any of these things.

While perhaps slight, this is a clear deniability advantage for
implicit auth vs. signature-based key agreement.


>>> Bob could be 6000km away without internet connectivity. This is very
>>> different from giving a "digital signature" that requires Bob to use
>>> a passphrase or pin to create it (eg PGP)
>>
>>
>> But it's also different from an implicitly authenticated, all-DH key
>> agreement.  Such a key agreement does not create 3rd-party verifiable
>> digital signatures *at all*.  Thus full transcripts can be forged more
>> easily, without interacting with Bob.
>
>
> Again, I am not a cryptographer, but I wouldn't say "make easier" is a
> very compelling reason to change the crypto (neither is "DSA is hard",
> one should be using standard and verified crypto libraries)

To be clear: I'm not advocating that OTR should change.  But
TextSecure is a different story, it's younger, it has a single
codebase, it's already a simplified EC variant of OTR, and it's going
through other changes currently.

Regarding (EC)DSA - it lacks good security proofs, it leaks the
private key if you have a biased RNG, it requires transmitting
signatures, and it's an additional algorithm which you can ignore with
a pure-DH handshake.


[....]
> When someone sniffs all traffic, they basically have the keys to easilly
> create forgeries with the libotr command line tools available to
> everyone. If the mac keys were not leaked, it needs more then just a
> network sniffer - one needs access to one of the two end point machines.

OK, but you need access to one of the two end point machines anyways
if you're going to get the signatures and full transcript to
cryptographically prove to a 3rd party that this MAC key is bound to
the endpoint.

If you can get these things, you don't need the published MACs, and if
you can't get these things, you won't be able to prove anything to a
3rd party anyways.  So what's the threat model here?

(And since the MAC keys are SHA1 hashes of the encryption keys, this
means you're publishing data about your encryption keys through a
suspect hash function, which isn't that cool....)


> While Peter and I are specifying the OTR protocol as an IETF draft, it
> is pretty important that _cryptographers_ (not protocol designers) look
> at this new tripple DiffieHellman variant,

Sure, it's been analyzed by Kudla and Paterson:

http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf


> have a significant advantage. Aside from the previously mentioned
> reasons ("DSA is hard" and something with MAC forgability that is still
> not clear to me) the other argument was message size. With fragmentation
> supported in OTR, and only the SMS network being stuck to such small 140
> character limit, I find this argument not very appealing either.

More deniable, simpler, smaller messages, fewer and more trusty crypto
algorithms.

(And if you wanted faster (though a bit less simple) you could do MQV,
which is about half the computation.)

So I think it's very reasonable for newer protocols that care about
deniability to prefer implicit-auth key agreement over
signature-based.


Trevor