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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
