[OTR-dev] mpOTR project

[Ximin Luo]

On 17/12/13 16:32, Gregory Maxwell wrote:
> 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.
> 

I should correct "or" to "and" in the 2-party OTR case.

> 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).
> 

Right, this way of describing "deniability" is more accurate. However, in a real-world scenario, the "network attacker" would be colluding with your attacker that is trying to use your non-repudiability against you, so the logging device does not need to be objectively "cheatproof", just "trusted by your attacker".

In any case, it would be better if we can come up with a better word than "deniable" or "off-the-record". "No reduction in deniability" is the full description of the property, but that is clearly too long to write.

And, I agree it's useful, but we shouldn't spend a disproportionate amount of effort trying to solve it, at the expense of producing a working multi-party protocol that has the other properties {auth,conf,fwd-sec}.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131217/e461806d/attachment.pgp>