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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
