[OTR-dev] mpOTR project

[Ximin Luo]

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?

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.

My comment is out of ignorance, similar to when people say "decentralised systems don't scale" - I'm not claiming an absolute proof of this, just a suspicion based on current knowledge. If anyone comes up a construction that does this well (including solving the tradeoff vs authenticity that I mentioned earlier), I would be super super excited. (George briefed me a bit just now, and I'll also have a read of the DSKE stuff that Maria posted.)

However, *even if you achieve it*, I would still strongly propose that we stop calling it "deniability" or "off-the-record", for the "misleading-users" reasons I detailed elsewhere.

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.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131217/4fbb0b8d/attachment.pgp>