[OTR-dev] mpOTR project

[George Kadianakis]

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?

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.

If you like MACs, what's the MAC key? Is it the key derived from the
group key exchange? 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.

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.

My feelings about deniability (non-repudiation and forgeability) are
mixed, and I have confessed them in this list before. Personally, I
have stopped thinking about deniability because it confuses me and I
don't really believe in it; instead I'm focusing on other aspects of
multiparty-chat protocols. I'm happy that other people are thinking
about deniability.

PS: BTW guyz, OTR uses signatures so it's not fully deniable either :3