Why Corporate Message Recovery isn't GAK
-----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)
Jon Callas <jon@pgp.com> writes:
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.
I won't even bother dealing indivdually with your arguments to this one because you have just demonstrated again your ability to simultaneously focus on hair splitting trivia, and ignore the whole crux of the argument. Suffice to say that it is not the details of the GAK (government access to keys) system that the US government has tried to coerce people to use that makes people not like it. It's what it means: it means that government will have access to keys. We have had what some people term Clipper I through Clipper IV (or is that V)? The details and the names change each time. And were you to be their spokesperson you would be explaining in intricate detail how "key recovery" is not "key escrow" and how therefor it is ok, and we should all accept it. The argument against pgp 5.5 is that it does 3 things wrong: 1. it is GAK compliant; it provides a ready to roll GAK system for the US administration to try to leverage into place and switch on 2. it attempts to provide escrow features for transient communications 3. it doesn't differentiate between storage keys (which should be escrowed to protect encrypted information stored on hard disks and backup tapes) and transient communications keys which should if anything be securely wiped after use
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.
I'm glad that you acknowledge the very real problem.
But I don't think it's feasible that CMR can be a stalking horse for GAK.
I notice that none of your reasons are technical. I take this to be a tacit acknowledgment that you have indeed built a GAK compliant system with pgp5.5. Let's have a look at these balances to see how comforting they are given the lack of technical protection (being a cypherpunks I like technical protections, they are so much more useful and concrete than words of assurance):
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.
Why would they have to buy the company? They would just introduce legislation to enforce _use_ of a feature you have already thoughtfully included. (A couple of people speculated that this early GAK compliance may be the result of PGP Inc corporate investor pressure (the share holder is god), or perhaps high level management decision that this allows an easy route for PGP whatever the outcome of the GAK wars: mandatory GAK PGP wins with it's early compliance, if mandatory GAK loses, well PGP continues to cash in PRZ's reputation, and PGP Inc's business client base). My question to you is what is PGP Inc going to do when becomes illegal to sell software which doesn't include mandatory GAK? What're you all going to do? Break the law? It'll be too late by then, unless you have a corporate contingency plan of moving to Switzerland. Do you?
(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.
The company would survive with staff replacement. Especially with mandatory GAK as the regime.
(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.
No problem. They'll just pay higher wages with the huge government sell-out dividend reaped by being a early GAK adopter (via GAK compliance).
(4) Stop the OpenPGP process in the IETF. [...] If OpenPGP succeeds, then anyone can build an interoperable version of PGP, not just us, Highware, Systemics, etc.
Stopping the OpenPGP process doesn't sound necessary, if I read your other post correctly PGP Inc would like to persuade the IETF to put GAK compliance features in the OpenPGP standard as a MAY right now. If you have your way, it'll be ratified by the time GAK comes. You might like to consider this thought also: Even if you personally believe that PGP Inc will stall at mandatory GAK, and cease trading rather than do it, or even if you personally will resign (I can't see that anyone's resignation helps us after the fact): other OpenPGP implementors may not. TIS or IBM or one of the other bona-fide GAKware government sell out types will take the opportunity to create an interoperable mandatory government access to key system. This is a BAD thing. You could prevent that. But you're not, you're helping it head to fruition. You will have to live with your conscience if GAK happens through this route.
(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.
Mr linux hacker will figure it out. Mr windows user won't. There are more Mr windows users.
There are also a few details left, like shutting down all those international FTP sites, but hey, they're the government, they're omnipotent.
This game isn't about Mr crypto-anarchist, linux hacker, it's about mass market software, about what individuals and companies are using. The spooks know they can't stop "live free or die" types using steganography even after mandatory GAK. Won't make it any less painful for those who don't have the nerve or technical expertise. I would say that I am not trying to be vindictive, or anything here, but you are _so_ easy to criticize, and I am trying to do what I can to encourage PGP to salvage the situation. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
participants (2)
-
Adam Back -
Jon Callas