Subject: Re: Plausible deniability (a feature to think about)

From: [email-masked] ("Hal Finney")
Date: Thu, 22 Sep 2005 09:51:08 -0700 (PDT)

Daniel Nagy writes:
> Imagine, that a conspiracy expects to be infiltrated. They send encrypted
> messages back and forth but they have a dilemma: to sign or not to sign? If
> they do sign, the infiltrator will have damning evidence on his hands and
> the bad guys will be able to crack down on the conspirators. If they don't
> sign, the infiltrator will be able to forge messages and thus seriously
> interfere with the activities of the group (e.g. call off action in the name
> of the ringleader, etc.).

These kinds of stories are often used to motivate cryptographic
constructions, but the real world generally doesn't work that way.
An infiltrator does not need cryptographic proof of his information
about who is in the conspiracy!  After all, he doesn't have any such
proof in the physical world, yet infiltrators, informants and spies have
long been used as valuable sources of information.

I admit to a fondness for fancy crypto and it would be fun to see some
form of deniable authentication in OpenPGP, but realistically it is not
going to meet our customers' needs.  If we do want to pursue it, there
are a number of technologies, like the DH shared keys you describe,
the signed ESK packets Vedaal mentioned, or ring signatures and other
variants of Chaum's designated-confirmer signatures.

Hal Finney

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 22 Sep 2005 20:20:29 +0200

> long been used as valuable sources of information.

I don't fully agree. Obviously, I wrote the story about the conspiracy and
the infiltrator with tongue firmly embedded in cheek. That's a long-standing
tradition in the crypto community and I certainly enjoy it. But
nevertheless, in many cases the presented scenario is precisely what
happens, just there's a lot less pathos surrounding it:

The overwhelming majority of "goverment agents" "infiltrating"
"conspiracies" are not politically motivated counter-intetlligence
operations but tax audits. A tax auditor pretends to be a customer and buys
someting. He sure as hell needs a rock-solid third-party proof to crack down
on you if you fail to report that income.

Now, what is taxed and what is not (by law!) depends on what is easy to tax
and what is hard to tax. If something is easy to tax, laws are passed and it
gets taxed. If something is hard to tax, if it's necessary for the functioning
of the society, it is not taxed, if it's not necessary, then it's outlawed.

Right now, e-commerce falls into the hard-to-tax-but-necessary category, but
the arms race is on. I'd certainly like it to stay the way it is.

While commerce is the single biggest user of crypto, there are other uses,
which we cannot even imagine. I don't have any reason to doubt that the
activist who wrote me about the missing feature in PGP could really use it.

Since ePointSystem is first and foremost a financial cryptography
consultancy, the first application on my mind was deniable invoicing. It's a
fair choice: either you use undeniable invoices, pay your taxes and resolve
your disputes in court relying on government enforcement, or you use
deniable invoices, don't pay taxes, and rely solely on reputational
self-regulation. I am pretty sure that most e-commerce will get taxed like
everything else, as soon as governments sort out their jurisdictional
problems. Having working deniable invoices would be a powerful argument in
the ensuing debate over taxation policies.

> going to meet our customers' needs.

How do you know? In my experience, predicting what people will use your
product for is one of the most difficult tasks an engineer or a scientist
faces. People are amazingly inventive.

>  If we do want to pursue it, there

All of which have slightly different characteristics and are therefore
optimal solutions for slightly different problems. In all cases, however,
interoperability is a major boon, and thus it's ITEF's business to provide
for it, isn't it?

DH shared keys and signed ESK packets are both very easy to incorporate into
the OpenPGP framework, and if we do it early on, we can hope that different
implementations will interoperate right away.

-- 
Daniel