[OTR-dev] mpOTR project

[Trevor Perrin]

On Wed, Dec 18, 2013 at 8:10 AM, George Kadianakis <desnacked at riseup.net> wrote:
> Trevor Perrin <trevp at trevp.net> writes:
>
>> On Tue, Dec 17, 2013 at 11:33 AM, Ximin Luo <infinity0 at gmx.com> wrote:
>>> On 17/12/13 17:40, Trevor Perrin wrote:
>>>> On Tue, Dec 17, 2013 at 7:41 AM, Ximin Luo <infinity0 at gmx.com> wrote:
>>>>> On 17/12/13 08:17, Мария Коростелёва wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>
>>>> <snip>
>>>>
>>>> I'd like to hear more explanation why you think deniability is
>>>> inherently "hard" and "complicated" for the multiparty case.
>>>>
>>>
>>> Ah, I was only talking about the multiparty case. Does that idea extend to mpOTR?
>>
>> I'm not sure what your vision of "mpOTR" is.  There seem to be
>> different ideas on that.
>>
>> 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.


> If you like signatures (I think you don't), you need to do an
> ephemeral signature exchange like the mpOTR paper suggests; that's
> complexity.

Yes, sounds complicated.


> If you like MACs, what's the MAC key? Is it the key derived from the
> group key exchange?

My example doesn't have a "group key exchange".  It has separate key
agreement between each pair of participants.


> If it is, you need to guarantee entity
> authentication, since everyone in the group knows the MAC key, but you
> still want to defend against in-group forgeries. It's not obvious to
> me if the "consensus check" described in the other thread is enough to
> defend against in-group forgeries.

I don't think so, the messages containing the consensus-check need to
be authenticated from an "entity".


> Also, the security proof is more involved for deniable protocols. I
> don't think there is a proof of security for the OTR protocol; or even
> proof that it's deniable. I'm talking about proofs like the Raimondo
> et al. proof of the deniability of SKEME ("Deniable Authentication and
> Key Exchange").
>
> The above points are not terribly bad, even though they certainly add
> complexity IMO. It gets worse if we also want forgeability. To achieve
> this, you need to have a shutdown phase, reveal keys, etc. These are
> messy and complex stuff. Let alone that I haven't seen a proof of the
> forgeability of a protocol.

In my example above, deniability adds zero complexity and simply
occurs for free, by using a 2-party protocol with that property.

And in a 2-party protocol like TextSecure, deniability adds zero
complexity and simply occurs for free, by virtual of using a DH-based
key agreement.

So I disagree that deniability "certainly" adds complexity.


Trevor