[OTR-dev] mpOTR project

[Trevor Perrin]

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,
>>>>
>>>> My supervisor Dennis Gamajunov and me have developed a summary on mpOTR protocol to see the whole picture of it. Later we plan to implement it making some kind of model implementation of mpOTR. So it would be wery nice to hear your opinoins about what we've done so far.
>>>> Our notes is here: http://mpotr.secsem.ru/mpOTRDev. I gotta say that it's in Russian but I hope this won't stop you, you can use Google Translate for example.
>>>>
>>>> Just to make it clear: we decided to use Improved «Improved Deniable Signature Key Exchange for mpOTR» [0] at Authentiction and Key Exchange phase and classical OldBlue [1] at Communication phase.
>>>> There are some problems we faced that are stated in «Questions to disuss» part http://mpotr.secsem.ru/mpOTRDev/quest. We provide some solutions but it'll be cool to hear some other ideas.
>>>>
>>>> Cheers,
>>>> Maria Korosteleva
>>>>
>>>>
>>>> [0] http://matt.singlethink.net/projects/mpotr/improved-dske.pdf
>>>> [1] http://matt.singlethink.net/projects/mpotr/oldblue-draft.pdf
>>>>
>>>>
>>>
>>> Haven't had time to read through the wiki yet, but just wondering, what are your ideas on deniability? Some of us want to drop this property because it's really not that strong[1], and requiring it makes other parts of the protocol harder / more complex. Because of this, we also intend to drop the name "mpOTR", on the basis that deniability and "off-the-record" can be misleading for a non-technical user.
>>
>> Hi Ximin,
>>
>> I dispute that deniability necessarily makes protocol design harder or
>> the resulting protocol more complex.
>>
>> In the 2-party case, Moxie and I argue that a strong notion of
>> deniability is achieved for free when one chooses modern
>> Diffie-Hellman based key agreements, which is the best choice for
>> other reasons:
>>
>> https://whispersystems.org/blog/simplifying-otr-deniability/
>>
>> 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.


> For the time being, my personal opinion is that the benefit of {OTR-deniability without strong deniability} doesn't justify the cost being taken to try to achieve it. But this is just a personal opinion, I don't have a proper economic argument for it.

I think until you have a clearer idea what your multiparty protocol
looks like, you're not going to know what the real tradeoffs are.

So making decisions about which security properties should be
abandoned seems premature at this point.


Trevor