[messaging] Value of deniability
infinity0 at pwned.gg
Wed Dec 10 14:21:24 PST 2014
On 10/12/14 22:24, Eleanor Saitta wrote:
> On 2014.12.10 16.12, Ximin Luo wrote:
>> There are a bunch of reasons why deniability doesn't "work in the
>> field". Once we neutralise those reasons, it would "work in the
>> field". For example, metadata leaks and bad endpoint security. So
>> blaming "it doesn't work in the field" on deniability itself, is
>> unfair - it's other things that are the real root of the observed
> This amounts to saying that "as soon as we have a magic wand that
> makes computers secure, deniability will be useful". The reason
> deniability doesn't work is that when the police present a transcript
> in court, they're believed because they're the police. Not because of
> the signature status or lack thereof of the transcript. Why do you
> think that having better endpoint security would make deniability more
> effective? All I hear is a repeated assertion that this is true.
Systems that provide unlinkability would help to prevent those transcripts from being leaked. Better endpoint security would also help. It's a matter of reducing risk - it will always be there, but taking measures to reduce it helps the end result. Not sure how I can explain it in other terms that would be more acceptable to you as a non-assertion...
>> As far as I'm concerned, the issue of deniability is resolved, we
>> don't need to talk about it any more.
> Great, I'm glad to hear that, because it's in direct contradiction
> with everything else that anyone has said on this subject.
To give some more detail, for (n+1)sec the main points of discussion were/are:
- whether the key really needs to be contributive
- whether it's acceptable to indicate "chat initiated" before confirming that everyone is present with a fresh key, or if it's OK to indicated "chat initiated" without confirming it (but confirming it when the first message is received from each)
- how much we can assume the transport to be reliable / well-ordered
- specifics of how to define / achieve consistency, and timing rules
- misc things like freshness and rekeying strategies
*Who* has been saying deniability is costing us? I do remember this point being passed around at last year's CCC, and maybe it was true for previous efforts - but for the efforts over the past year, we haven't really run into this at all.
>> My point in this previous paragraph was that you can't "roll back"
>> the lack of deniability.
> Yes, I know. My point is that it's not clear that the lack of
> deniability is relevant to the security evaluation of a protocol.
> If it has literally zero cost? Sure, great, let's have protocol
> deniability. If it has absolutely any cost? I'd much rather see
> all of that effort go into things that we know actually matter, like
> doing basic requirements evaluations before designing a protocol, as
> it's not clear if was done in the n+1sec case.
> : The other case of deniability, hidden information repositories
> inside disk or file encryption systems, is in almost all cases a
> direct harm to users.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Messaging