[OTR-dev] Simplifying deniability

[Gregory Maxwell]

On Tue, Jul 30, 2013 at 1:32 AM, Trevor Perrin <trevp at trevp.net> wrote:
> I'm not sure what publishing MAC keys adds.  Gregory wrote:
[...]
> The transcripts I was talking about represent complete protocol runs.
> AFAICT, Gregory's just describing "making up" an AES key and some
> plaintext, encrypting it, then splicing it into a bunch of ciphertext
> and claiming it came from Bob.

OTR ships with tools that allow you to flip arbitrary message bits in
a transcript and preserve the MAC passing. If you can guess the
plaintext or know the AES key you can make arbitrary modifications. If
you do not, you can simply pick an AES key, and under that assumption
replace the text with whatever you like, this is isomorphic to just
encrypting some new plaintext— but with the OTR transcripts you can
still update the authentication so you end up with a transcript that
passes authentication as being from the parties in question.

> why can't the attacker make up a new MAC key, too?

IIRC because the attacker cannot produce the signatures authenticating
the mac key for the keys belonging to alice and bob. The transcript
would not be plausible.  This is directly related to the "partial
reputability" mentioned in your citation.

I'm skeptical that the stronger denyability is of any practical value:
as I recall in the OTR protocol the only denyability limit is that
each leaked transcript increases a minimum bound on the number of
times alice and bob's identity has been observably used. (E.g. it
doesn't produce evidence that alice and bob talked to each other (as
you could forge that), it doesn't tell you when alice or bob talked,
etc.)

On the flipside, I think that the alternatives I've seen lose their
zero knoweldge relative to a third party "observer" when one of the
communicating parties cooperates with the observer in order to pre-set
the random values (allowing them to distinguish a simulation from a
real transacript). But it's been a while since I looked at any of this
stuff or OTR itself.

The purpose of my message was mostly to whine about an apparent lack
of understanding of what OTR was doing, especially in light of the
fact that libotr includes tools for forging transcripts and such.  I
didn't analyze the proposed protocol.