From: Jon Callas <jon@pgp.com>
Date: Sat, 11 Oct 1997 06:34:06 +0800
To: ietf-open-pgp@imc.org
Subject: Why Corporate Message Recovery isn't GAK
Message-ID: <3.0.3.32.19971010151206.00a122b0@mail.pgp.com>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are two things I will discuss in this missive:

(1) The assertion that Corporate Message Recovery is "just like Clipper"
and why this is not true.
(2) The fear a number of people have expressed that Corporate Message
Recovery (CMR) could be used by the US government to slide in GAK. 

I think we're agreed that CMR isn't itself GAK and I'll talk some about why
it isn't with (1).

CMR isn't like Clipper:

* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
bits or more), backed with a full-strength public key.

* Clipper's key was set in hardware by the manufacturer, and users were
required to use it. A CMR key is a software-enabled key, no user is ever
required to use it. There are cases in which a user might "volunteer" to
use a CMR because they work for someone who requires it, but that's a
problem we'll address with the PGP Secure Resume Server which allows
headhunters to securely and anonymously find people who've made bad career
decisions.

As a corollary of of the previous paragraph, there's no reasonable
guarantee with a Clipper device that you haven't been black-bagged with an
insecure key. Using a CMR may be unwise, but at least you knowingly did it
to yourself.

* A CMR key can be revoked, reissued, or changed. You can periodically
change it as a matter of policy. You can even stop using it. Clipper's was,
again, set in hardware, with no option of not using it. 

* The Clipper symmetric algorithm was secret; CMR keys use publicly
available algorithms.

* With Clipper, there was always a concern that an outside agency had the
keys. This is true with a number of other systems (the so-called key
recovery systems), and is the reason that a number of them are lumped
together with the term GAK. Note that the user-organization creates a CMR
key, and the end-user enables it. If any government gets access to this
key, it is because either (1) they solved the Discrete Logarithm Problem,
(2) they broke the public CMR key, (3) they black-bagged your CMR key, or
(4) they are using a subpoena, warrant, or discovery to get the key. We're
working on a way around (1), we can't do anything about (2) or (3), but
these are fine reasons not to use CMR! If you're beset by (4), you need
lawyers, not cryptographers.

* With Clipper, there was a central repository of all the keys. With CMR,
there is not. I discussed that in detail in my message, "Why Corporate
Message Recovery isn't Key Escrow."

I have noticed that a number of people have the tacit assumption that
business people and corporations are in cahoots with the FBI, waiting to
hand over everyone's secret key. As in all parts of life, there are many,
many businesspeople and corporate execs who are not particularly moral. But
I don't think that their immorality takes this form. If we could examine
the dark, secret thoughts of a corporate scumwaffle -- the ones that he
*really* hopes don't hit the papers -- I sincerely doubt that, "Oh, Louis,
I love it when you rummage my drawers" is among them.

Now then, the next topic is the fear that CMR will be used in some
insidious government plot to slip in GAK everywhere.

I worry about this, too. But I don't think it's feasible that CMR can be a
stalking horse for GAK. If the government wants to GAK-enable all PGP,
they'll have to have a plan similar to this:

(1) Buy PGP, Inc. Since our worth is less than the black portion of the
Federal Budget, this is not impossible. Would that it were otherwise. Heck,
we're probably worth less than the black portion of New Zealand's budget.

(2) Fire all the current development staff. This isn't very hard. All the
new bosses have to do is round us up in a meeting and announce, "The next
version of PGP will have a 40-bit export option." We'll say, "Not while
*we're* working for the company!" They'll say, "Fine with us." Keep your
eye on the secure resume server for clues of this event.

(3) Hire a new staff. This is one of the places that the plan might fall
apart. We have such a hard time finding anyone who's qualified to work for
us that we have reqs we can't seem to fill. I suppose, though, that they'll
be able to find some people willing to relocate from Maryland.

(4) Stop the OpenPGP process in the IETF. Some people think that we did
this as part of our Evil Plan to Take Over the World by Giving Away
Software (hey, it almost worked for Netscape). Other people think it's part
of our Evil Plan to Take Over Crypto by Using Unpatented Algorithms. I can
neither confirm nor deny these, but I *will* tell you that it's part of our
Sniveling Plan To Convince the Feds They Can't Kill PGP by Killing Us,
which the source code books also fall into. If OpenPGP succeeds, then
anyone can build an interoperable version of PGP, not just us, Highware,
Systemics, etc.

(5) Wait until bitrot makes all those existing copies of PGP stop working.
I could make a few catty remarks about how quickly existing software stops
working on new releases of OSes, but you've probably thought of them yourself.

There are also a few details left, like shutting down all those
international FTP sites, but hey, they're the government, they're omnipotent.

	Jon



- -----
Jon Callas                                         jon@pgp.com
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQA/AwUBND6mO335wubxKSepEQKpgQCeNxWHHjIucyzRrQV429PKM0sTykAAnjiz
byD3SzToLdfkGq+mIyUHji6M
=r8nx
-----END PGP SIGNATURE-----


-----
Jon Callas                                         jon@pgp.com
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)