[messaging] Axolotl: Lacking deniability or MITM?

[Natanael]

Den 24 nov 2014 22:47 skrev "Alexey Kudinkin" <alexey.kudinkin at gmail.com>:
>
> Hey guys!
>
> Cruising around Axolotl spec recently, i’ve just stumbled upon one grit
constantly disturbing me:
>
> https://whispersystems.org/blog/simplifying-otr-deniability/

[...]

> Those two seems kinda mutually exclusive: if we do actually have an
authenticated key exchange, then we’ re losing so promising statement of
deniability, since any one could authenticate us during the handshake.
> The other way around, lacking authenticity, we’re making ourselves prone
to MITM unless there is an established channel to verify public keys.

The key to this is that there's a difference between after-the-fact forging
and live authentication. When you are one part of the exchange, *those
particular session keys* are generated by you together with the other
endpoint. You don't accept anything sent to you with arbitary keys you did
not generate, or if the key exchange authentication fails. *You know the
source of the keys*.
And afterwards the temporary secrets involved in the PFS scheme is deleted.

With the forging method mentioned, the source is unknown for transcripts of
conversations you weren't part of *and THEREFORE any source is equally
plausible*.

Sure, the person you're talking to can be certain what you're saying comes
from you. But that's kind of the point, why would you want to use it if you
didn't also know you can trust that the messages you receive haven't been
tampered with our that the people you talk to can be certain they got
genuine untampered messages?

And more to the point - no matter how certain *they* are, they can't in
turn prove it to others due to the fact that those third parties weren't
part of your key exchange, so anything from that transcript becomes
hearsay. (For an interesting reversal of this concept, see tlsnotary.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141124/a19dfee7/attachment.html>