[Top] [All Lists]

Re: Just say NO to key escrow or CMR/ARR revisited

1997-11-05 00:05:44
At 12:16 -0700 on 11/04/1997, Gene Hoffman wrote:
On Tue, 4 Nov 1997 mark(_at_)unicorn(_dot_)com wrote:

At the same time, it builds a 'feature' into every copy
of PGP which could at some point in the future be used to provide
government access to messages by forcing users to encrypt to a government
key. This, to Adam and others (including me), is so great a risk that
we'd much prefer key escrow or an alternate system.

It would take the same amount of government intervention to corrupt a
corporate key escrow system as CMR.

Requiring access to plaintext via a system using either CMR (easier) or
corporate key escrow (slightly harder) would probably be well within the
capabilities of your average government to arrange.

However, there is one crucial difference between CMR and corporate key
escrow.  This difference leads me strongly _away_ from any kind of system
that requires (or could be abused to require) encryption of messages to 3rd
party keys.

Think of what the adversary who wants to abuse CMR on a large scale would
have to do, vs the task facing the adversary who wants to abuse a corporate
key escrow system.

Compare and contrast workload:

With CMR (encryption to 3rd party keys), in a likely implementation
scenario, the attacker only has to require encryption of all messages to a
corporate/ISP/city/county key, which they also hold or can steal, for
decryption at will.

With corporate key escrow, to achieve the same effect, the attacker will
need to require access to or steal copies of each key.

At an average of only 10,000 users per corporate/ISP/city/county "recovery"
key, CMR reduces the workload and storage needs of the attacker by 4 orders
of magnitude.  Throw in a province-wide or regional government recovery
key, and you reduce the storage needs of the attacker (not necessarily the
government) by 10 orders of magnitude or more.

This is a serious bottom-level security flaw with the basic CMR idea as
implemented in PGP 5.5.  It is too scalable, to the benefit of an attacker.

Implement message recovery outside open-pgp:

To achieve message recovery when necessary, corporate key escrow
implemented _outside_ the open-pgp standard (on a per-application basis) is
the more secure and reasonable alternative.

I would thus greatly prefer that the open-pgp standard not specify any kind
of encryption to 3rd party keys.

Of course, there is also no need for it to specify how any kind of key
escrow might be done.

Let's keep open-pgp simple, and leave message recovery to each application
developer who sells into markets where such features are desired.