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. Trevor _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
