[OTR-dev] mpOTR protocol phases and research questions

[Trevor Perrin]

On Wed, Oct 23, 2013 at 4:18 PM, George Kadianakis <desnacked at riseup.net> wrote:
>>
>> On Wed, Oct 23, 2013 at 10:00 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>> Deniability is easily achieved if you just use Diffie-Hellman based
>>> key agreements without signatures
>>
>> Thats a whole lot of DH for a room with 100 people in it (3*N^2).
>
> Hm, 3*N^2 ? I guess that's for the pairwise authentication case.
>
> Can't the "triple-DH" protocol be used as part of a cyclic
> broadcast-based authenticated multi-party key agreement?

Maybe, but according to Van Gundy's email [1], mpOTR is looking to
move away from pairwise key agreement during DSKE anyways, and mix
deniable signature key exchange (DSKE) with a group key agreement
(GKA) due to Bohli.

I don't know much about that (is there a link to the Bohli paper)?

--

I'm new to mpOTR, so let me back up and ask the obvious question:  How
important is it to have group keys / deniable signature keys versus a
naive approach of:
 - pairwise authenticated key agreement
 - encrypting/MAC'ing each sent message to all other chat members
 - having the parties also send hashes of all 3rd-party messages they've seen

I imagine typical chat protocols are routed through a central server.
In that case, I'd think mpOTR only reduces total system traffic by
~half over the naive approach (it optimizes upstream bandwidth to
server, but the server still has to distribute that traffic downstream
to all recipients).

Also, mpOTR's signed messages could allow reconstruction of consensus
if a consensus error is detected (unlike MAC'd messages), but that
seems complicated and expensive in practice, and the mpOTR spec
doesn't describe the algorithms for doing so.  Is that a realistic /
useful feature for mpOTR?


Trevor


[1] http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html


PS: The Just-Vaudenay paper is interesting, I hadn't seen an MTI/A0
style "tripleDH" before (where the 3 DHs are multiplied instead of
hashed).  But you want hashing for "unknown key-share" (aka "identity
misbinding") defense, so I don't think it's an improvement...