On Tue, Jul 30, 2013 at 1:32 AM, Trevor Perrin <tr...@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. _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
