[messaging] Value of deniability
ella at dymaxion.org
Wed Dec 10 14:41:41 PST 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
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.
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.
> Concretely: imagine plea deal negotiations in a case where a
> digital transcript has been introduced as evidence. Do you think
> you might get a better deal if you can convincingly say in two
> minutes "look, here's how you would forge this transcript" or if
> you have to show the jury some fancy complicated hacker tools to
> forge the transcript? what if there was some "non-repudiable"
> cryptographic proof of origin for the transcript?
I can imagine it, but every lawyer that's been asked about that
scenario has basically laughed about it. I mean, sure, they might try
it -- in the course of a trial, you try a lot of things, most of which
you have no expectation of working, but that's entirely different from
giving the notion any plausibility.
> note that cryptographic deniability isn't really the biggest issue
> here -- people are convicted all the time based at least in part
> on cleartext, non-signed transcripts, possibly because lawyers
> aren't good at making arguments about the forgability of digital
> data yet, in part because we (the tech community) haven't given
> them the tools or the public mindshare to make this argument easy.
Un-signed and deniable are distinct properties. I'm definitely not
arguing against unsigned transcripts; making an active effort to make
repudiation difficult is a very different question than designing for
the field utility of deniability.
> 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.
Ideas are my favorite toys.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Messaging