On 17/12/13 17:40, Trevor Perrin wrote: > On Tue, Dec 17, 2013 at 7:41 AM, Ximin Luo <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
