[OTR-dev] mpOTR protocol phases and research questions

Trevor Perrin trevp at trevp.net
Thu Oct 24 16:26:03 EDT 2013


I think Nadim's mail didn't make it to the list, but I'll respond to a
few things here...


On Thu, Oct 24, 2013 at 12:19 PM, George Kadianakis
<desnacked at riseup.net> wrote:
> Nadim Kobeissi <nadim at crypto.cat> writes:
>
>> I've replied to George inline, so please read that first, but I also have some side-points:
>>
>
> Hey Nadim!
>
>> 1) We should not forget to discuss the issue of synchronous vs. asynchronous messaging.

Yeah, easier key agreement in the async case is one of the main
reasons TextSecure is moving to Triple-DH.   Triple-DH (or MQV etc)
can be implemented as a single unordered exchange of messages (unlike
SIGMA, which requires 3 or 4 ordered messages).

Though note OTR's use of hash-commitment for short SessionIDs also
requires a 3-step handshake, so that's a tradeoff to be pondered, as
is identity-hiding.


> I'm also of the opinion that deniability is making protocol design,
> reasoning and implementation harder.

For a 2-party case, I don't think it's deniability as much as OTR's
approach to deniability making those things hard.  If you do key
agreement right deniability is free.

MpOTR makes deniability more complex as it tries to implement
"transferability" of message authentication via signed messages, so
"the protocol can identify malicious users, since an honest party
Alice has transferable proofs to convince any other honest party about
the origin of the messages that she received"

If we're doing to debate "arguably overcomplex features that could
perhaps be removed", I think this use of transferable-but-deniable
signing should be on the table...


> c) Deniability *might* be easier than expected. The implicit DH-based
>    protocols that Trevor has been talking about are good
>    examples. From a first glance, I don't think they require
>    complicated shutdown() procedures either.

Publishing signature and MAC keys could be made unnecessary with
deniable key agreement.

Any multiparty chat protocol will need to check consensus by having
parties broadcast hashes of the messages they've received.

mpOTR puts that in shutdown() which doesn't seem ideal, but that's a
certain amount of work that's unrelated to deniability, and which
could be moved around but I don't think eliminated.


Trevor



More information about the OTR-dev mailing list