On Wed, Dec 18, 2013 at 9:56 AM, Ximin Luo <[email protected]> wrote: > On 18/12/13 17:07, Trevor Perrin wrote: >> On Wed, Dec 18, 2013 at 8:10 AM, George Kadianakis <[email protected]> >> wrote: >>> Trevor Perrin <[email protected]> writes: >> >> In my example the "multiparty" protocol was simply pairwise "2-party" >> protocols. >> >> So the multiparty case inherits all the mechanisms of the 2-party >> case, and also inherits the "deniability" properties of the 2-party >> protocol, whatever those are. >> >> Ximin was saying it's infeasible to construct a multiparty >> communication protocol with deniability. I'm giving a trivial >> counterexample. >> > > Inheriting security properties is a tricky thing. I haven't thought of any > particular security problems with this (yet) - though it's pretty inefficient.
Not necessarily. In some contexts, multiparty communications will require separate messages being sent to each participant anyways (e.g. Pond). In the case of a central chat server, sending a message will ultimately result in N-1 delivered messages. Does it matter whether the sender has to transmit O(N-1) bytes to the server for a sent message, or O(1)? It's not clear. And if getting to O(1) requires a dozen communication rounds to establish "deniable signature keys" and "group keys" (a la mpOTR), then my naive proposal might be *more* efficient. > To make the point explicit, the consensus check is to make sure that Alice > isn't telling different versions of the conversation to different people. It > is something on top of the 2-party case that you have to do, just to preserve > consistency. I think you get this for free with the DAG stuff we talked about > in the other thread, though, as long as the message hash ID is hashed over > the (constant) message content stripped of the (per-recipient) MAC. Yes, I was thinking on those lines - you'd still have to do the consensus checking. > BTW, my original email wasn't supposed to discourage anyone else from trying > to achieve deniability, or to attack anyone who is trying to do this. I'm > curious as to what other people are doing, because of the difficulties we ran > into with it. OTR for me is more than just deniability. (And sorry if I > offended some background cultural thing where attacking deniability is a > no-no.) No worries - not offended - I just think this needs more analysis before we start jumping to conclusions about what is and isn't doable. Trevor _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
