[OTR-dev] mpOTR project

[Ximin Luo]

On 17/12/13 16:33, Dennis Gamayunov wrote:
> 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?
> 

As we've been talking about "mpOTR", would provide forward secrecy (not the case for PGP) and be end-to-end decentralised (not the case for SILC).

What's your user scenario where you find OTR-deniability to be useful? You understand that if your partner (who is logging your ciphertext) is colluding with the NSA (who is logging everyone), there is no "deniability" that you could argue in court? (IANAL)

OTR-denability is "we can reject a strong claim (a proof)". Intuitive deniability would be "we can strongly reject a claim", including metadata (hard!). Another alternative is "we can strongly claim (prove) the rejection", which is probably impossible, but I mention it for completeness, because some people get confused between the forms.

> 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

You can't guarantee that others will follow protocol and edit the transcript in that way, similar to how you can't guarantee that your partner isn't logging the plaintext.

-- 
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/6623e881/attachment.pgp>