On Wed, Oct 23, 2013 at 4:18 PM, George Kadianakis <[email protected]> wrote: >> >> On Wed, Oct 23, 2013 at 10:00 AM, Trevor Perrin <[email protected]> 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... _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
