[messaging] Value of deniability

[moderncrypto at mkern.fastmail.fm]

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, moderncrypto at mkern.fastmail.fm 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.