[messaging] deniability data point

[Jeff Burdges]

On Fri, 2016-10-28 at 17:16 -0700, Sam Lanning wrote:
> Now that we've added crypto to the mix, a lot of the time people try
> to claim something was forged / doctored, and they don't realise
> there's proof that that's not the case. They can no longer make the
> same claim, and instead have to claim that a certain device was
> hacked, they had a piece of malware that stole secret data etc... and
> that's a claim that's a lot harder to make stand up in court.

Agreed, but..

We want deniability for political reasons, so we should worry if
deniability seemingly might cause the opposite result. 

Just consider a transcript being use against an individual by federal
agents.  We might or might not agree with what this individual has done.
We as cryptographers, developers, etc. should choose the defendants'
side though for an array of reasons that largely parallel the legal
presumption of innocence.  We like good cops just fine, but bad cops,
bad states, etc. should be at the bottom of the list of people we want
to see our tools help.

We should extended Matt Green's sentiment to :  We cannot expect a
"cryptographic CSI effect" in which juries, or judges, expect
cryptographic proof the way the television show CSI supposedly made
juries expect more physical evidence. 

As you observe, all deniability achieves is to prevent the cryptography
from providing proof that someone is a liar.  

There are always good odds the defendant is lying, even if they're
innocent.  It's a sure bet, they are cut off from their chat
transcripts, and cannot remember the situation accurately.  Ain't so
hard imagining a defense attorney convincing a jury that a defendant
honestly believed a transcript said something wrong though. 

There are shockingly good odds the cops are lying too, irregardless of
the defendant's guilt.  I'd hope catching cops in lies did enormous
damage to their case, although who knows if/when that's holds.  And
maybe that makes deniability a net negative socially.


I believe we've a more subtle case for deniability however :  

Right now, we're building simply messaging applications, but
increasingly we'll be building transport layers for more complex
applications, which often require signatures anyways.  A private git
repository with anonymous contributors might still require signed
commits.  

I suspect we want deniability when available just to minimize the
interactions of signatures between higher level protocols that run over
the channel.  

You might for example wish to make payments over your channel.  We have
extremely strong anonymity for *customers* in Taler for example,
probably much stronger than other anonymous transactions schemes like
Monero or Zerocoin provide to *payers*.  Afaik nobody has attempted to
do a UC proof of anonymity for even a simple blind signature scheme
though.  Worse, we use a cut n' choose scheme in our refresh protocol.
And commitments never play nicely with UC security proofs.  

Absent any UC proofs, we cannot foresee the properties of protocol
interactions, so minimizing those interactions seems wise. 

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20161030/1b186c41/attachment.sig>