[OTR-dev] mpOTR project

Gregory Maxwell gmaxwell at gmail.com
Tue Dec 17 11:32:33 EST 2013


On Tue, Dec 17, 2013 at 8:18 AM, Ximin Luo <infinity0 at gmx.com> wrote:
> It's also unethical to silent change my quote to read something I didn't say. If you were making some subtle point, it was lost on me.

Do you mean to suggest that you actually have an ability to refute a
non-cryptographically attested transcript? And that someone might
believe your claim that it was forged?  Interesting.

> The protocols I am hearing about, you do have deniability if all participants are honest and throw away the handshake secrets and logs (the authentication/signing is done by ephemeral keys), but this breaks if any are dishonest or if there is a network attacker. *This is the case for OTR too*. So I think we shouldn't advertise it as "deniable", in the same way I don't think OTR is actually "deniable" or "off-the-record".

This isn't the case in OTR. Feel free to save your entire state— all
your ephemerial secrets, everything— along the entire communications
sequence. The resulting transcript you receive can still be forged by
you.

In, instead, you hypothesize a "cheatproof" logging device connected
outside of the remote party— then indeed, with the aid of the
cheatproof logging device a forged transcript can be identified, at
least so far as you trust the device. But with such a device along the
path there was nothing denyable about a plaintext conversation either.
 It sounds like you are adopting a model where no protocol can have
denyability and missing the idea that the point of OTR is to achieve
the outcome where the addition of cryptography makes the users
denyability no worse then it would have been absent the cryptography,
for all those threat models where it does make a difference (arguably
all of them, because cheatproof logging devices do not exist— but it's
a more significant improvement in some cases rather than others).



More information about the OTR-dev mailing list