[messaging] Value of deniability

[Ximin Luo]

On 10/12/14 22:00, Eleanor Saitta wrote:
> On 2014.12.10 15.52, Ximin Luo wrote:
>> Yes, deniability won't prove the lack of authorship in legal 
>> settings, because in current systems there's lots of other
>> evidence that suggests (or "proves-in-court") authorship. However,
>> once we have systems that provide unlinkability, then deniability
>> becomes more useful - so better to build it in now.
> 
> By which mechanism does it become more useful?
> 

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

>> I don't understand the source of this perception that people have 
>> "been wasting time" on it, though. The delay in doing end-to-end 
>> group chat hasn't been because of deniability, but other more 
>> structural issues around the fact that it's a group chat.
> 
> Interesting.  It's my understanding (and apologies if I'm wrong on
> this) that the complexity around deniability rules out a large number
> of possible solutions that provide the other set of properties we
> might like.  The question I asked on libtech was about where
> requirements were sourced from and, for instance, the work that was
> done in providing deniability in (n+1)sec without providing any kind
> of moderator-kick ability at the protocol level, the former not being
> something we see any field demand for and the latter being absolutely
> critical in most real uses.
> 

The vast majority of work on (n+1)sec was not about deniability. Deniability is not complex - there have been key exchanges with similar properties for many years - deniability is essentially a form of ZKP. Getting group and ordering semantics to work reliably was more complex, and there's much more work to be done in that area. As far as I'm concerned, the issue of deniability is resolved, we don't need to talk about it any more.

>> Generally, we want to have the maximum security for ourselves -
>> which includes the inability for our recipients to prove to 3rd
>> parties that we sent a message. So this should be the "default"
>> security property to aim for.
> 
> No, we want to have the set of security properties that have proven
> field utility and we can roll back from there.  I agree with the logic
> of this paragraph, but not your evaluation of the starting point.
> 
>> As per the OP's situation, sometimes it could be useful to set up
>> an additional social contract along the lines of "I don't want to
>> talk to you unless you give me the ability to prove to 3rd parties
>> that you said this", we can easily do it on top of a deniable
>> system - by signing everything again inside the deniable channel.
>> But we can't build deniability on top of signatures. So it's best
>> to start off with deniability as the base security property for a
>> channel.

My point in this previous paragraph was that you can't "roll back" the lack of deniability.

X

-- 
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: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141210/e2b181a2/attachment.sig>