THE INTERNET CODE RING! An Interview with Phil Zimmerman, creator of PGP We were sitting in a circle on the floor at the Computers, Freedom, and Privacy conference, March '93 in San Francisco, St. Jude and I with Tom Jennings, Fen La Balme, et al, discussing encryption and other neophiliac rants when a dapper fellow wandered by with a beard on his face and a tie hanging from his neck. He picked up Jude's copy of bOING-bOING number 10 and glanced through it, clearly interested. I later learned that this was Phil Zimmerman, creator of PGP ("Pretty Good Privacy"), so I tracked him down and we talked for the record. Jon: I'm fairly nontechnical, and I'm also new to encryption. I spent some time recently on the cypherpunks' list, and I have a pretty good sense of what's going on, but maybe you can tell me in your own words how you came to write PGP, and what your philosophy is, especially with distribution. Phil: Well, okay. PGP, which means "Pretty Good Privacy" is a public key encryption program, it uses a public key encryption algorithm, which means that you can encrypt messages and you can send them to people that you've never met, that you've never had a chance to exchange keys with over a secure channel. With regular encryption, the kind that everybody has heard about, you encrypt a message, it scrambles it up, renders it unintelligible, and then you send it to someone else, and they can descramble it, decrypting it. They have to use the same key to decrypt it as you used to encrypt it. Well, this is a problem, this is inconvenient, because how are you going to tell them what that key is, what're you going to do, tell them over the telephone? If someone can intercept the message, they can intercept the key. So this has been the central problem in cryptography for the past couple of millenia. There's been a lots of different ways of encrypting information, but they all have this problem. If you had a secure channel for exchanging keys, why do you need any cryptography at all? So, in the late 1970s, somebody came up with an idea for encrypting information with two keys. The two keys are mathematically related. You use one of the keys to encrypt the message, and use the other key to decrpyt the message. As a matter of fact, the keys have a kind of yin-yang relationship, so that either one of them can decrypt what the other one can encrypt. So everybody randomly generates a pair of these keys, the keys are mathematically related, and they can be split apart like cracking a coin in half, and the jagged edges stick together just right. They can publish one of the keys, and keep the other one secret. Now, unlike cracking the coin in half, you can't look at the jagged edge, and figure out what the other jagged edge is going to look like. In fact, you can't look at the published key and figure out what the secret key is without spending centuries of supercomputer time to do it. This means that any time anybody wants to send you a message, they can encrypt that message with your public key, and then you can decrypt the message with your secret key. If you want to send them a message, then you can encrypt the message with their public key, and then they can decrypt it with their secret key. Everybody who wants to participate in this system can generate a pair of these keys, publish one of them, and keep the other one secret. Everybody's published key can end up in a big public key directory, like a phone book, or an electronic bulletin board, or something like that. You can look up somebody's public key, encrypt a message to them, and send it to them. They're the only ones that can read it, because they're the only ones that have the corresponding secret key. J: Are there any such directories now? P: Well, actually, there are starting to be directories like that. For PGP, there are some public key directories on Internet. You can just send an electronic inquiry saying "Give me the key for [somebody]," and it'll send you their key back, their public key. J: The convention I've seen has been the inclusion of the public key in an email message posted to a mailing list. P: You can do that, you can include your own public key when you send a message to someone, so that when they send you a reply, they'll know what public key to use to send the reply. But the problem...there is an achilles heel with public key cryptography, and I'll get to that in a minute. But first, let me explain authentication. If I want to send you a message, and prove that it came from me, I can do that by encrypting it with my own secret key, and then I can send you the message, and you can decrypt it with my public key. Remember I said that the keys are in this yin-yang relationship, so that either one can decrypt what the other one encrypts. If I don't care about secrecy, if I only cared about authentication, if I only wanted to prove to you that the message came from me, I could encrypt the message with my own secret key and send it to you, and you could decrypt it with your public key. Well, anyone else could decrypt it to, because everyone has my public key. If I want to combine the features of secrecy and authentication, I can do both steps: I can encrypt the message first with my own secret key, thereby creating a signature, and then encrypt it again with your public key. I then send you the message. You reverse those steps: first you decrypt it with your own secret key, and then you decrypt that with my public key. That's a message that only you can read and only I could have sent. We have secrecy and authentication. So you get authentication by using your own secret key to decrypt a message, thereby signing the message. You can also convince third parties like a judge that the message came from me. That means that I could send you a financial instrument, a legal contract or some kind of binding agreement. The judge will believe that the message did come from me, because I am the only person with the secret key, that could have created that message. Now, public key cryptography has an achilles heel, and that achilles heel is that, suppose you want to send a message to someone, and you look up their public key, on a bulletin board, for example. You take their public key and you encrypt the message and then send it to them, and presumably only they can read it. Well, what if Ollie North broke into that BBS system? And he subsituted his own public key for the public key of your friend. And left your friend's name on it, so that it would look like it belonged to your friend. But it really wasn't your friend's public key, it was Ollie's public key that he had created just for this purpose. You send a message, you get the bulletin board to tell you your friend's public key, but it isn't your friend's public key, it's Ollie's public key. You encrypt a message with that. You send it, possibly through the same bulletin board, to your friend. Ollie intercepts it, and he can read it because he knows the secret key that goes with it. If you were particularly clever, which Ollie North isn't because we all know that he forgot to get those White House backup tapes deleted...but suppose he were clever, he would then re-encrypt the decrypted message, using the stolen key of your friend, and send it to your friend so that he wouldn't suspect that anything was amiss. This is the achilles' heel of public key cryptography, and all public key encryption packages that are worth anything invest a tremendous amount of effort in solving this one problem. Probably half the lines of code in the program are dedicated to solving this one problem. PGP solves this problem by allowing third parties, mutually trusted friends, to sign keys. That proves that they came from who they said they came from. Suppose you wanted to send me a message, and you didn't know my public key, but you know George's public key over here, because George have you his public key on a floppy disk. I publish my public key on a bulletin board, but before I do, I have George sign it, just like he signs any other message. I have him sign my public key, and I put that on a bulletin board. If you download my key, and it has George's signature on it, that constitutes a promise by George that that key really belongs to me. He says that my name and my key got together. He signs the whole shootin' match. If you get that, you can check his signature, because you have his public key to check. If you trust him not to lie, you can believe that really is my public key, and if Ollie North breaks into the bulletin board, he can't make it look like his key is my key, because he doesn't know how to forge a signature from George. This is how public key encryption solves the problem, and in particular, PGP solves it by allowing you to designate anyone as a trusted introducer. In this case, this third party is a trusted introducer, you trust him to introduce my key to you. There are public key encryption packages currently being promoted by the U.S. Government based on a standard called Privacy Enhanced Mail, or PEM. PEM's architecture has a central certification authority that signs everybody's public key. If everyone trusts the central authority to sign everyone's key, and not to lie, then everyone can trust that they key they have is a good key. The key actually belongs to the name that's attached to it. But a lot of people, especially people who are libertarian-minded, would not feel comfortable with an approach that requires them to trust a central authority. PGP allows grassroots distributed trust, where you get to choose who you trust. It more closely follows the social structures that people are used to. You tend to believe your friends. J: Did you make a conscious decision up front, before you started programming PGP, that you were going to create something that would be distributed in this grassroots way, free through the Internet. P: Well, there were some software parts of PGP that I developed some years ago, as far back as 1986, that I developed with the intention of developing commercial products with it someday. Over the years that followed, I developed a few more pieces that I hoped someday to turn into a commercial product. But, when it finally came down to it, I realized that it would be more politically effective to distribute PGP this way. Besides that, there is a patent on the RSA public key encryption algorithm that PGP is based on. I wrote all of the software from scratch. I didn't steal any software from the RSA patent holders. But patent law is different from copyright law. While I didn't steal any software from them, I did use the algorithm, the mathematical formulas that were published in academic journals, describing how to do public key cryptography. I turned those mathematical formulas into lines of computer code, and developed it independently. J: Did you originally intend to license that? P: When I first wrote the parts of it back in 1986, I did. But I began in earnest on PGP in December of 1990. At that time, I had decided that I was going to go ahead and publish it for free. I thought that it was politically a useful thing to do, considering the war on drugs and the government's attitude toward privacy. Shortly after I stared on the development, I learned of Senate Bill 266, which was the Omnibus Anticrime Bill. It had a provision tucked away in it, a sense of Congress provision, that would, if it had become real hard law, have required manufacturers of secure communications gear, and presumably cryptographic software, to put back doors in their products to allow the government to obtain the plain text contents of the traffic. I felt that it would be a good idea to try to get PGP out before this became law. As it turned out, it never did pass. It was defeated after a lot of protest from civil liberties groups and industry groups. J: But if they could get away with passing it, they would still take the initiative and try. P: Well, yeah, actually...it started out as a sense of Congress bill, which means that it wasn't binding law. But those things are usually set to deploy the political groundwork to make it possible later to make it into hard law. Within a week or so after publishing PGP, Senate Bill 266 went down in defeat, at least that provision was taken out, and that was entirely due to the efforts of others, I had nothing to do with that. PGP didn't have any impact, it turned out, at all. So that's why I published PGP. J: Several of my friends are involved in cypherpunks, and I've been on their mailing list...are you affiliated in any way with cypherpunks? Are you getting their mailing list? P: I was on their mailing list for a couple of days, but I found that the density of traffic was high enough that I couldn't get any work done, so I had them take me off the list. J: The reason I bring cypherpunks up is that they seem to have almost a religious fervor about encryption <laughs>. I was wondering if you share that. P: I don't think of my own interest in cryptography as a religious fervor. I did miss some mortgage payments while I was working on PGP. In fact, I missed five mortgage payments during the development of PGP, so I came pretty close to losing my house. So I must have enough fervor to stay with the project long enough to miss five mortgage payments <laughter>. But I don't think it's a religious fervor. J: I'm impressed with the way encryption in general and PGP in particular have caught on with the press, how it's become within the last year. P: Well, PGP 1.0 was released in June of '91. It only ran on MS DOS, and it didn't have a lot of the features necessary to do really good key certification, which is that achilles' heel that I told you about. Theoretically, you could use it in a manual mode to do that, but it wasn't automatic like it is in PGP 2.0 and above. The current release of PGP is 2.2. It's a lot smoother and more polished that 2.0 was. 2.0 was tremendously different than 1.0, and the reason the popularity has taken off so much since September, when it was released, is because it ran on a lot of UNIX platforms, beginning with 2.0. Since the main vehicle for Internet nodes is UNIX platforms, that made it more popular in the UNIX/Internet world. Since Internet seems to be the fertile soil of discourse on cryptography, the fact that PGP 2.0 began running on UNIX platforms has a lot to do with it's popularity since that version was released...Tthat was in September of '92. J: The easiest way to get PGP is through FTP from various sites? P: Yeah. Most of them European sites. PGP 2.0 and above was released in Europe. The people that were working on it were out of reach of U.S. patent law...and not only are they out of reach of patent law, but it also defuses the export control issues, because we're importing it into the U.S., instead of exporting it. Also PGP 1.0 was exported, presumably by somebody, any one of thousands of people could have done it...but it was published in the public domain. It's hard to see how something like that could be published, and thousands of people could have it, and it could not leak overseas. It's like saying that the New York Times shouldn't be exported, how can you prevent that when a million people have a copy? It's blowing in the wind, you can't embargo the wind. J: And by beginning in Europe, you sort of fanned the flame that much better. P: Yeah. J: It seems to have spread globally, and I'm sure that you're hearing a lot about it, getting a lot of response. P: Particularly at this conference (CFP93), yes. J: Do you plan to do more development of PGP, or are you satisfied with where it is.... P: PGP will be developed further. My personal involvement is more in providing design direction and making sure that the architecture stays sound. The actual coding is taking place overseas, or at least most of it is. We do get patches sent in by people in the U.S. who find bugs, and who say, "I found this bug, here's a patch to fix it." But the bulk of the work is taking place outside the U.S. borders. J: Is there a Mac version as well as a DOS version now? P: Yeah, there is a Mac version...there was a Mac version released shortly after PGP 2.0 came out. Somebody did that independently, and I only found out about it after it was released. People have written me about it, and it did seem to have some problems. The same guy who did that version is doing a much improved version, Mac PGP version 2.2, which I believe should be out in a few days...that was the last I heard before I came to the conference. The second Mac development group, that's working on a very "Mac"-ish GUI, is being managed by a guy named Blair Weiss. That takes longer, it's difficult to write a good Mac application, so it's probably going to be a couple of months before that hits the streets. J: Were you involved in the UNIX version, too? P: I did the first MS-DOS version entirely by myself, but it's not that big a distance between MS-DOS and UNIX, so most of it was the same. The UNIX board took place soon after PGP 1.0 was released. After that, many other enhancements were added, and major architectural changes took place to the code, and that's what finally made its way out as version 2.0. J: You're doing consulting now? P: That's how I make my living, by consulting. I don't make anything from PGP. J: Do you think you'll just let PGP take a life of its own, let other people work on it from here out? P: Other people are contributing their code, and other people are adding enhancements, with my design direction. Perhaps someday I'll find a way to make money from PGP, but if I do, it will be done in such a way that there will always be a free version of PGP available. J: I was thinking of the UNIX thing, where everybody's modified their versions of the UNIX Operating System so that some [customized versions] weren't even interoperable. I was wondering if there was a chance that PGP would mutate, whether you're going to keep some sort of control over it, or whether people will start doing their onw versions of it.... P: Well, I don't know, that could happen. There are so many people interested in the product now, it's hard to keep track of everybody's changes. When they send in suggested changes, we have to look at it carefully to see that the changes are good changes. J: But you don't have some sort of structure in place where you do some kind of approval if somebody wants to make some kind of mutant version of PGP.... P: There is a kind of de facto influence that I have over the product, because it's still my product, in a kind of psychological sense. In the user population, they associate my name with the product in such a way that, if I say that this product is good, that I have looked at this and that I believe the changes made sense the last version are good changes, that people will believe that. So I can determine the direction, not by some iron law, not by having people work for me that I can hire and fire, but more by my opinion guiding the product. It would not be easy for a person to make a different version of PGP that went in a different direction than how I wanted it to go, because everybody still uses the version that I approved, so to be compatible...this has a kind of intertia to it, a de facto standard. PGP currently, I believe, is the world's most popular public key encryption program, so that has potential to become a de facto standard. I don't know what that means in comparison to the PEM standard. PEM is for a different environment than PGP, perhaps, although the PGP method of certifying keys can be collapsed into a special case that mimics in many respects the PEM model for certifying keys.