[OTR-dev] mpOTR project

Ximin Luo infinity0 at gmx.com
Tue Dec 17 11:18:29 EST 2013


On 17/12/13 16:04, Gregory Maxwell wrote:
> On Tue, Dec 17, 2013 at 7:41 AM, Ximin Luo <infinity0 at gmx.com> wrote:
>> Haven't had time to read through the wiki yet, but just wondering, what are
>> your ideas on deniability? Some of us want to drop this property because
>> it's really not that strong[1], and requiring it makes other parts of the protocol
>> harder / more complex. Also, we are being paid by a state entity to get all
>> messages cryptographically signed. Because of this, we also intend to drop the name
>> "mpOTR", on the basis that deniability and "off-the-record" can be misleading
>> or a non-technical user.
> 
> I think it is unethical to offer chat protocols that silently create
> cryptographic non-repudiation where none was requested or expected by
> the user.  The user thought they were increasing their security, but
> in some cases they were actually decreasing it. Yes, it isn't that
> strong against "strong" attacker who are "trustworthy" where people
> would believe a fabricated log regardless, but that is only one class
> of attacker many are not so easily trusted.
> 
> If you want to go and build a harmful thing— thats your business. But
> why are you posting to the OTR mailing list?
> 

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.

How weak "deniability" works in 2-party OTR, exploits the hole in its authenticity - if you didn't write the message, you assume the other party wrote the message. In multi-party OTR, this doesn't work, unless you assume all participants are trustworthy, which is even more dangerous. In other words, there is a trade-off to be made between authenticity and deniability. I think authenticity is more fundamental and important, in case someone goes and silently changes what I say.

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

If you can propose a way to have actual strong deniability as I defined in that other thread, as well as authenticity, I'd be for it. I don't know of enough crypto magic to provide these properties, and the people I am talking to don't either.

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/68f80a7b/attachment.pgp>


More information about the OTR-dev mailing list