[OTR-dev] mpOTR project

Dennis Gamayunov gamajun at seclab.cs.msu.su
Tue Dec 17 11:33:30 EST 2013


Hi, Ximin,

17.12.2013 19:41, Ximin Luo пишет:
> 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. X [1] see the otr-users thread, "The effectiveness of
> deniability", starting Nov 29, last message December 06.
I was not on that list, but similar subdiscussions occured here on
otr-dev as well.

For me personally deniability is the mpOTR' primary difference from
various older secure chats (i.e. SILC, PGP-backed XMPP). If the
resulting protocol lacks this feature, I would expect new projects to
come to fill this niche. So, why don't we try to address the need of
deniability right now, while the protocol development is still in progress?

It's true that there might be very little practical difference between
"digitally signed proof" and "proof with a broken digital signature" in
some of the real-world scenarios. But maybe we could address these
scenarios in some other way? For example, during the shutdown phase we
are free to change the session transcript in arbitrary way, and
communicate it between participants. These manipulations could add bogus
messages into the transcript, or rework it so that user profiles in
terms of language use would be identical, or enforce some other
characteristics of transcript.

Maybe it would be possible to keep the transcipt sceleton intact, to
make it accessible and searchable for the user off-line, but modify in a
way that would render impossible for the 3rd party to use it as a proof
of anything.

Dennis



More information about the OTR-dev mailing list