[OTR-dev] mpOTR project

Wed Dec 18 05:07:16 EST 2013

Hmm, guys, could please make it clear for me what do strong deniability and
weak deniability mean?
And what's the difference between repudiation/non-repudiation and
deniability? I may lack some knowlege of English here.

And how this all matches up with the basic idea to mimic real-world private
conversations?
As far as I can see all the things we are trying to do with chat transcript
are aimed to mimic the situation that no such transcript have ever existed.

>However, in a more complex scenario that is IMO closer to the real world,
even
>though J understands B/M may not be honest, they might assume partial
honesty -
>i.e. that it is costly to forge evidence, and that the sheer amount of
evidence
>can count for "proof" even though it technically could be forged. Here, we
want
>strong-deniability.
>
>This is why Big Brother can't just claim that all of Larry Leaker's
documents
>are made up - the amount of information revealed makes this claim
unplausible.
>It's also why anonymity is hard, because all you need there is balance of
>probabilities.
>
>Even in real-world meetings, someone can record your voice. They could
forge
>the recording, but a high-enough quality recording would be analogous to a
>cryptographic signature - the amount of effort to produce it would be
thought
>of as "infeasible", and the balance of probabilities swings in the favour
of
>the attacker.
>

Of course if someone makes a record of conversation *real-world situation*
and then gives it to the judge
it'll be a strong proof of a claim that some person participated in chat or
said something that is recorded and smth like that.
But do we count such situations?  Don't we assume that we mimic only
off-the-record conversations?
Because in real world this situation would mean that you were a fool to
trust such a person and to invite him to your private meeting.
Can we take this formula for mpOTR too?

May be I didn't get something, sorry then

2013/12/18 Ximin Luo <infinity0 at gmx.com>

> On 17/12/13 20:56, Jacob Appelbaum wrote:
> > Ximin Luo:
> >> 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.
> >
> > Generally speaking, we discuss protocols in terms of repudiation and
> > non-repudiation. The word deniable is a mapping of common understanding
> > with the less than common meaning of the word repudiation.
> >
>
> I'm fine with equating repudiable/deniable; my complaint was instead
> directed
> at using these labels without any sort of qualifier. There are lots of
> non-cryptographic information leaks, which make certain forms of OTR
> transcripts non-repudiable in a court.
>
> As I mentioned elsewhere, "no reduction in deniability (compared with
> plaintext
> chat)" is more appropriate. However, to call OTR simply "deniable",
> "repudiable", "off-the-record" or any similar thing, implies that it has an
> *advantage* in this area over plaintext chats, when it does not.
>
> By contrast, the (theoretical[1]) plausible-deniability property of a
> censorship-resistant publishing platform like Freenet *does* have an
> advantage
> over plaintext storage - since the node operator doesn't have the keys to
> decrypt the documents he is hosting, he cannot be held responsible for
> them.
>
> [1] yes, I'm aware that in practise Freenet probably has holes; my
> argument is
> abstract. You can replace "Freenet" with the theoretical "Eternity
> service" if
> that makes you more comfortable.
>
> > SILC exists for group chats if you want an encrypted multi-party chat
> > protocol with non-repudiation (in a court, from a forensics perspective,
> > etc etc).
> >
> > If people are going to re-invent SILC, why not ensure that they don't
> > make the same mistakes?
> >
>
> I only heard about SILC today, but browsing the RFCs[1][2][3], I don't see
> mpOTR as simply "SILC with deniability". SILC has these deficiencies
> compared
> to mpOTR:
>
> - end-to-end encryption is optional and not well-specified [1#section-5]:
> "if
> the client requires .. not trusting any of the servers .. it can be
> accomplished by negotiating private secret keys outside the SILC Network"
>
> - message source authenticity is also an afterthought [3#section-2.3.2.6]:
> "This flag indicates that the message is signed with sender's private key
> .. A
> separate document should define [this]." This is consistent with the
> security
> section [1#section-5] omitting that clients might not trust *each other*.
>
> [1] http://tools.ietf.org/html/draft-riikonen-silc-spec-09
> [2] http://tools.ietf.org/html/draft-riikonen-silc-ke-auth-09
> [3] http://tools.ietf.org/html/draft-riikonen-silc-pp-09
>
> --
> GPG: 4096R/1318EFAC5FBBDBCE
> git://github.com/infinity0/pubkeys.git
>
>
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131218/72cd8a22/attachment.html>