On 18/12/13 14:20, Ximin Luo wrote:
> 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.
> 

By "good enough", I mean in an overall, "strongly deny" sense. Of course, the 
case I outlined above is no better than the plaintext case, where your ISP can 
log your plaintext too, and add weight to your attacker's claims that you said 
something.

I should take a break; I'm omitting things from my points because I'm rushing 
to write replies.

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

And, due to the "recording" issue, I believe that potentially we can do 
*better* with an OTR protocol, than in a real-life conversation. You reveal far 
less information when you type bytes, than when you speak; it's what's in the 
middle of the internet that screws with your deniability.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OTR-dev mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev

Reply via email to