[OTR-dev] Simplifying OTR Deniability
jacob at appelbaum.net
Mon Jul 29 09:53:15 EDT 2013
> On Sun, Jul 28, 2013 at 11:46 PM, Arlo Breault <arlolra at gmail.com> wrote:
> I'm a bit confused by
> "It’s true that by publishing old MAC keys, anyone is capable of
> modifying the ciphertext of a previously observed message. However,
> even if that person can guess the plaintext and is capable of making
> predictable modifications to the ciphertext via a malleable encryption
> scheme, they still can’t demonstrate valid plaintext to anyone else
> without the cipher keys (and if they had those, they would be able to
> calculate the MAC keys anyway).
> What’s more, since the initial OTR key exchange is signed and
> transmitted through an unobservable channel (an “outer” ephemeral key
> exchange), it’s not actually possible for anyone to produce what
> appears to be a conversation with you."
> In the context of the fact that libotr actually ships with tools for
> creating these "not actually possible" transcripts.
Indeed - for those looking - the code for this is in libotr.git/toolkit.
Debian and Ubuntu offer binary packages as well:
> In particular, you can just _make up_ an AES key, modify the
> transcript to say whatever you want assuming that AES key and you get
> a completely plausable transcript which you know the AES key for that
> appears to be between the named parties.
> Am I missing here or is the above quote some really scary commentary
> to be coming from someone who claims to be 'improving' OTR?
I had similar thoughts. Though I generally dislike plain old DSA - I
think switching to a very different design and claiming the old
properties of the protocol is a bit off the mark. Specifically, it is
the case that Moxie's new protocol may offer similar features to OTR -
though this remains to be studied, understood and so on.
All the best,
More information about the OTR-dev