[OTR-dev] mpOTR project

Trevor Perrin trevp at trevp.net
Wed Dec 18 15:30:39 EST 2013


On Wed, Dec 18, 2013 at 9:56 AM, Ximin Luo <infinity0 at gmx.com> wrote:
> On 18/12/13 17:07, Trevor Perrin wrote:
>> On Wed, Dec 18, 2013 at 8:10 AM, George Kadianakis <desnacked at riseup.net> wrote:
>>> Trevor Perrin <trevp at trevp.net> 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



More information about the OTR-dev mailing list