On Wed, Dec 10, 2014, at 23:41, Eleanor Saitta wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2014.12.10 17.12, Daniel Kahn Gillmor wrote: > > On 12/10/2014 04:49 PM, Eleanor Saitta wrote: > >> On 2014.12.10 16.31, [email protected] wrote: > >> > >>> The practical value of deniability at the protocol level would > >>> be much higher if it was deeply integrated into the user > >>> interface of (commonly used) client software. > >> > >> Under which specific scenario would this improve security > >> outcomes for users? > > > > Under the scenario where a judge or jury is confronted with the > > situation that a transcript introduced as evidence might be > > forged. > > > > Making transcript forgery tools not only easy to use but > > immediately visible to anyone who has ever used the tool would most > > likely make it easier to make a convincing case that a purported > > transcript is not "ground truth". > > > > This isn't a slam-dunk legal argument, and it's certainly not > > guaranteed to get anyone out of trouble, but getting any part of > > the legal system to cast a more skeptical eye at digital evidence > > could certainly "improve security outcomes for users" faced with > > legal charges.
Daniel's example is close to what I was thinking of. Easy ways to forge the transcript, if widely adopted, lead to a better understanding from people that digital evidence is easy to forge unless cryptographically signed, which in turn increases the benefit of actually having protocols which are deniable (instead of signed). If half the jury has used a version of whatsapp where the history is easy to change and they are presented with evidence in the form of a chat log from that app (often this is even done with screen shots) then their base level of confidence in the evidence will be very different. Widespread deployment and awareness of such mutability would improve the outcome for all users in the long run. > It's not a legal argument, it's an argument about the chain of > evidence. The rebuttal is a sworn oath from the officer in charge of > the evidence that it hasn't been tampered with, and it stops there. I'm not qualified to comment on whether it would be any sort of legal argument and indeed it might not be in general. There might be cases however where evidence of earlier conversations between two accused is brought up. If at that point it is not clear who of them made which statements it might well bolster the defense of either or both of them. > There is, as far as I can tell, absolutely no situation outside a > court room where this is even relevant, so it's a niche argument at > the absolute best, albeit a potentially important niche. There are plenty of mundane, everyday situations of course where people show each other chat transcripts as "proof" of what someone else said. None of these require deniability at the protocol level though since nobody would bother to check. It seems you are asking for an example where a) the stakes are high enough to warrant close inspection and b) the situation is such that doubt about the originator of a message has actual benefit to the user. A court room seems indeed to be the only place where b) applies. I wouldn't call that a niche though. [...] > > cryptographic deniability is still not a huge win. but if we get > > it for free, i see no reason to dismiss it. > > We don't. Maintaining it as a technical property adds another > invariant to the system that must be tested for in both the protocol > and the documentation. If that legal case example is to be remotely > plausible, it must be documented and communicated to users. The > number of complex invariant concepts that a user can understand and > then use in their planning is strictly limited; adding deniability as > a property we support in a system actively adds cognitive load to the > system. If one intends to design in a way that actively encourages > people to see the deniable nature of the system, such as the > aforementioned editable transcripts, we now have to look at what other > kinds of user errors are being introduced in the course of their > normal task completion and what the added cognitive load of the > supporting features are. > > There is never, ever, ever such a thing as a "free" security invariant > in a system when looked at from the perspective of end-user efficacy. I agree that this introduces an additional concept for the user to understand if they are to make good use of this feature. However if you sign messages instead then you have to educate the user about the fact that there is no way for them to repudiate the messages they send. _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
