From: tcmay@netcom.com (Timothy C. May)
Date: Fri, 25 Mar 94 21:10:34 PST
To: cypherpunks@toad.com
Subject: (fwd) THE INTERNET CODE RING - PGP info
Message-ID: <199403260548.VAA06765@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Cypherpunks,

I found this in alt.wired tonight. I don't recall seeing this
particular interview published before, but I could be losing track of
what's out there---Zimmermann has been interviewed a lot.

We (Cypherpunks) are mentioned in the interview.

--Tim May


From: jsquires@nic.cerf.net (James A. Squires)
Newsgroups: alt.wired
Subject: THE INTERNET CODE RING - PGP info
Date: 23 Mar 1994 06:58:47 GMT
Organization: CERFnet
Lines: 370
Keywords: PGP

This was sent to me.  I found it a great explanation for how
PGP works (non-tech), and the concept of a public key.

It is an interview with the author.

Hope y'all find in useful ^_^
-JAS

--------------------------------------------------------------

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.

   --- [ End Of Line ] ---