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: >>> But could you build an N-party "deniable" communication protocol out >>> of a 2-party "deniable" protocol? >>> >>> Of course: Have each pair of parties execute the 2-party protocol. >>> To send a message, a party sends it to each of its N-1 counterparties, >>> along with a "consensus check" for the multiparty conversation. >>> >>> >>>> Anyway, I'm not trying to argue that it *necessarily* makes it hard. I'm >>>> only saying that my current knowledge does not suggest it's feasible, in >>>> the presence of other concerns like authenticity. >>> >>> I just solved it - feasibly - in the presence of that concern. >>> >> >> Well, you didn't specify the whole protocol :) And the whole protocol >> matters for deniabil^W non-repudiation. >> >> For example, the way each message is authenticated matters. Do you use >> a MAC or a signature? > > 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. That might not be a real-world concern - I mostly have private chats with 7-8 people max anyway. 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. 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.) -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
