[OTR-dev] mpOTR project

Ximin Luo infinity0 at gmx.com
Wed Dec 18 09:20:00 EST 2013


On 18/12/13 10:07, Мария Коростелёва wrote:
> 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.
> 

I just made those terms up; other uses outside this thread might mean something different, but-

- "weak-deniability" / "OTR-deniability" - "I reject a strong claim" - the transcripts don't have signatures that are linked back to you, anyone can forge them.
- "strong-deniability" - "I strongly reject a claim" - the things you did during the chat session don't produce evidence that can be used to identify your actions to an honest third party, including things outside of your control like your ISP logging the ciphertext, or your partner logging e.g. the session key.

> 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. 
> 

See also my last reply to Dennis. There are two attacks in a real-world private conversation, your partner can:

- reveal the transcript, without extra proof. There is no defence against this, but 3rd-party verifiers are also less likely to believe it; this is scenario (2) in my previous post. Real-life analogy would be your partner writing your words down on a piece of paper.

- reveal the transcript, plus some other information that allows 3rd-party verifiers to independently verify this transcript. This is scenario (3) in my previous post and the topic of these arguments. Real-life analogy would be your partner making a very high-quality recording of you.

OTR tries to prevent (3) by making the ciphertext forgeable ("weak deniability"). I argue that this is not good enough - if a separate attacker (e.g. your ISP) logs you sending the ciphertext to your partner, and your partner reveals the session key, this is extra evidence that is not present in the (2) attack case, so verifiers have more reason to believe it, than if the attacker simply just logged the plaintext.

>>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
> 

The main difference is the amount of evidence your attacker can provide to a 3rd-party verifier. I hope my paper/recording analogies cover this acceptably.

-- 
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/20131218/99806190/attachment.pgp>


More information about the OTR-dev mailing list