
-----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)