Note: Windows 95/NT and Macintosh version of PGP 5.0 freeware are available. This documetn does not apply to those versions. It does still apply to version 2.6.2, which is still the current Unix version. It will be maintained until some time after v2.6.2 becomes completely obsolete. In the meantime, I suggest that all Windoze/Crackintosh users upgrade immediately.
"Privacy is a right like any other. You have to exercise it or risk
losing it."
--Philip Zimmermann
-s signaturesDo you use email? Do you use usenet? Do you have a need for people to know that your messages in these media are not forgeries? Do you have a need to send sensitive information, such as your credit card number, over the net? Are you having a love affair? Are you engaged in illegal activities, or just activities you would rather people didn't know about? Pretty Good Privacy, or PGP, written by Philip Zimmermann, can help you fulfill all of these purposes. Read on. Are you a person who has nothing to hide? You still should be protecting your privacy. Don't think so? Read here for more from the author of PGP.
The technique PGP uses to accomplish all of these amazing feats of cryptography is called "public-key encryption." This is among the most sophisticated of cryptography methods. If you're familiar with the concepts of public-key encryption, then you can skip ahead to the bare bones.
Most people have at least heard of conventional crypto, if not by that name. This is the crypto used in simple ciphers such as those found in GAMES magazine, but on a much smaller scale. For example, this is a passage of plaintext.
The quick brown fox jumped over the lazy dogs.
Now, I am going to scramble that plaintext with a key and an algorithm. The algorithm defines what method is used, while the key cites a specific instance of the algorithm.
Uif rvjdl cspxo gpy kvnqfe pwfs uif mbaz epht.
On first glance, the ciphertext which you see after I apply the key appears incomprehensible. This is a very simple cipher, in comparison. Since I have provided the plaintext and the corresponding ciphertext, it should be very easy for you to deduce the key. But if you can't or, more likely, are lazy, like me, I will provide the key for you. Replace each letter in the plaintext with the letter immediately following it in the alphabet. Replace each letter in the ciphertext with the letter immediately preceding it in the alphabet. The algorithm could be said to be shifting the letters. The key is 1, because you shift 1 to the right. If you did deduce the key before I gave it to you, think about this: Would you have been able to if I had only provided the ciphertext? Try this.
Gur ynml qbtf jrer whzcrq ol gur sbk.
This is a better cipher of the same sort, the ROT-13 cipher, which is older than dirt, and is exactly the same as the one I just described, but the encryption and decryption processes are the same. It is used on usenet occasionally, to obscure something that people may not want to see, but if they do, then it's easy to figure out what it says. The key is to shift every letter 13 letters either way in the alphabet. (This cipher was cracked in the time of Caesar.)
PGP, as I've said already, uses a relatively recent technique called public-key encryption with two codes rather than one. These codes are related intrinsically, but it is not possible to derive one from the other. If you really want to know the disgusting, gory, technical details of RSA, look around. (Warning: there is math.) When you generate a key, two keys are created, of course, the public key and the secret key. You disseminate the public key as widely as possible, over the phone, the internet, keyservers, anything. The secret key you keep on your machine and use to decipher messages sent to you. So people will use your public key, which can only be decrypted by your secret key, to send you messages, and you will use your secret key, to, appropriately, read them. Why two keys? With conventional crypto, when transferring key information, a secure channel is required, for obvious reasons. And if you have a secure channel, why use crypto? But with the public-key system, it doesn't matter who sees your key, because the one people see is only used for encryption, and what's more, only one who has access to your secret key, or usually physical access to your machine, can decrypt messages encrypted with your public key, and then only if that person knows the passphrase. So someone could conceivably, with sneaky techniques, steal your passphrase as you type it, but only if they could get access to your computer could they actually read messages. But if you use common sense, no one will be able to read your messages.
The above applies to a pure public-key system. PGP is, isn't it? NO.
(Gotcha.) (Warning: the rest of this paragraph is chock full of techie
crap. If you are confused enough already and would just rather not know, skip
it.) Public-key is very slow compared to conventional, so PGP combines
two algorithms, namely RSA and IDEA, to encrypt your plaintext.
(If you don't understand the terminology I use, read the rest and then come back
to this.) For example, I want to encrypt a file called plain.txt
so that only my friend Bob Williams can decrypt it. I send PGP the command to
encrypt.
pgp -e plain.txt williams
In this command line, pgp is the executable file, -e
tells PGP to encrypt the file, plain.txt is the
name of the plaintext, and williams represents the public key I
want to use to encrypt the message with.
PGP uses a random number generator, in the file randseed.bin
to create a temporary IDEA session key. The session key itself is encrypted with
the RSA public key represented by Williams and tacked on to the
plaintext. Then, PGP uses the session key to encrypt the message, ASCII-armors
and saves the whole thing as cipher.asc. When Bob gets the
message, he types the command:
pgp cipher.asc
PGP uses Bob's secret key, which is an RSA key, to decrypt
the session key which, if you'll recall, was encrypted by his corresponding
public key. Then, conventional crypto is used in the form of the session key to
decrypt the rest of the message. The reason for doing this instead of straight
RSA because "RSA is too slow, it's not stronger, and it may even be weaker."
(-PGP Documentation, pgpdoc2.txt). Henceforth I will refer to this
entire process as encryption, or enciphering.
(Techie crap is over now, you can open your eyes.)
PGP uses sophisticated encryption algorithms to turn readable ASCII text or even a binary file into an uncrackable ciphered code. Here is an example.
After looking at this I think you will agree that PGP's ciphertext is better than pretty good. Look at it! Every line 64 bytes of absolute crap. Before you agree too strongly, let me say that that was the wrong way to analyse crypto software. Uncrackable ciphertext looks the same as bad ciphertext. If I ran the words of the ROT-13 ciphering which I did before together and varied capitalization, it would be identical to PGP ciphertext. So how do you know it's any good? Ask the U.S. Government. There was indeed a massive lawsuit against Philip Zimmermann which has only recently been dropped. (January.) There are a lot of encryption programs out there, but as the author said to NetGuide magazine, May 1995: "Which has the government most upset?"
The way PGP works is pretty easy to understand. You have two keyrings; a public one and a secret one. Your public keyring holds your public key and the public keys of people you know. Your secret keyring holds your secret key, or keys, depending on how many keys you have. Your public key is the one that your friends (or enemies) have to have so they can send a PGP-encrypted message to you. Then, you decrypt the message with your secret key. When I encrypt a message with my friend Bob's public key, ONLY Bob's secret key can decrypt it. I can't do it, even though I encrypted it. Again, to use a one-key system, which is less complicated, a secure channel, such as a face-to-face meeting or a trusted courier is required to transfer the key, and if you have such a good method of sending messages, you don't really need PGP, do you? With public-key encryption systems, the public key (encrypted so that PGP can read it) can be sent through email, while the secret key stays with you.
So I encrypt my message:
pgp -sea plaintext williams [-u drosoff]
which tells PGP to sign it with a secret key (s),
encrypt it with Bob's public key (e), and apply ASCII-armor (a).
williams is shorthand for Bob's key which should take the form:
Robert Bob Williams <[email protected]>
that is, the key-owner's name followed by his email address in pointy
brackets. -u specifies what secret key to use, i.e., my
secret key,
David Rosoff <[email protected]> to sign the message. (The
[brackets] denote an optional arg. Don't type the brackets. If you have
specified the MyName option in config.txt,
you do not need this. You can override config.txt with the -u
arg, however.) PGP asks for my secret key passphrase (so bad guys can't fake my
signature) and then says OK. I go into my mailer and put:
To: [email protected] Subject: PGP-encoded message <-----message text begins here-----> Dear Bob, How have you been out in Bobland? Again, I'm sorry that your parents were so heartless as to have named you "Bob." Did you know that Bob spelled backwards is ... you'll never guess ... Bob!? I know, it startled me too. Did you also know that all of life's wisdom can be found in anagrams, that's what I just did to your name, only anagrams don't have to be just backwards, but palindromes do, so I guess Bob is an anagram of itself, no, stifle is an anagram of itself. So I guess I'll see you later, and Neil says hey. David Rosoff
and then I use my mailer's "Read file" command to insert the file which contains the PGP message in the mail. (There are programs which help you integrate PGP into your mailer, like Private Idaho, which I am not discussing.) It ends up looking like this.
In the comment, I mentioned a decryption passphrase. PGP has the capability
to perform conventional encryption as well as public-key encryption, so
sometimes it's useful. (Of course, you don't have to put the passphrase in the
comment. That would be silly.) If you actually retrive PGP and save this file to
disk, you will be able to decrypt it and compare with the original, as well as
ensuring that it came from me. You can accomplish this using the
s arg in your command:
pgp -sea plaintext williams -u drosoff
That means to sign the plaintext with secret key drosoff,
encrypt the signed plaintext, and apply ASCII-armor
to the ciphertext. The general form for this command is as follows.
pgp -sea plaintext pubkey1 pubkey2 pubkey3 ... -u seckey
or
pgp -sea [text file] [recipient's pubkeys] -u [sender's seckey]
To utilise multiple recipients, just separate the keynames by a space.
pgp -sea plaintext williams johnson stevens -u drosoff
But back to signing a plaintext. This is to give assurance that the plaintext really did come from you, which can be very important in the internet, when it is becoming increasingly easier to tamper with messages. The genius lies in the fact that only you have your secret key.
Like I said before, your secret key is the ONLY key that can decrypt
messages that were encrypted with your public key. When I say signed with your
secret key, PGP looks over
the plaintext, makes a "digest message" to represent it, encrypts the
digest with your
secret key, appends that to the plaintext, and marks it as a
signature. The result of just a signature command (-st
or -sat) is a plaintext with a ciphertext at the bottom. Think of
Reader's Digest, where popular readings are
condensed. That's what PGP does, and then enciphers the condensed
plaintext with your secret key, creating the signature. This is where it gets
somewhat confusing, if it wasn't bad enough already. I have stated that public
keys encrypt, and secret keys decrypt. That's so for plaintext, but on
signatures, it's the other way around. (For my horridly confusing attempt to
clarify further, follow this link; but I suggest you
just accept it as a fundamental truth and move on.) To summarize, PGP creates a
unique checksum for your plaintext, unique because every plaintext is
different. Say that Bob posts on usenet. Both of you have PGP. He signs it, but
doesn't encrypt, which is the S.O.P. for usenet identity verification. (The
reasoning behind this is fairly evident; since you're posting to usenet anyway,
who cares who reads it? The signature is the important part.) He sounds a little
enraged, so you download the post and save it to disk to check its accuracy. If
the message has been tampered with along the way, your PGP will tell you that
the signature is bad. A bad guy can delete the signature along the way, but
then, of course you'll have no way to check and the bad guy might as well have
not bothered. What an awkward sentence. My English teacher would punch me in the
face. Sigh. You will only get a sig message, good or bad, if you have Bob's
public key. (Why? Because in signatures, the roles of encrypting key and
decrypting key are swapped. Bob's secret key was used to sign the digest; his
public key must be used to verify it.) Again, it's confusing, I know. If you
don't get it, email me and I'll help
you. The signature is different for each message, and only your secret key can
generate your signature. On the receiving end, PGP looks at your public key
(that the receiver has) and decides whether it was really your secret key that
sent that signature. If it is, PGP says something like Good signature
received from David Rosoff <[email protected]>. If not, it says
something like this.
WARNING, bad signature, doesn't match file contents
Anyone who has used a binaries group on usenet knows what uuencode is. It's
a program, mainly for UNIX, but now branching out, that turns binaries like
.GIF or .AU files into ASCII text suitable for
usenet posting. PGP can do that too. The config.txt file (may be
called pgp.ini or .pgprc in accordance with local
protocol) has an option for how many lines an ASCII file can contain. If this
number is reached, PGP breaks up the armored .asc file into
.as1, .as2, .as3, ... and all one must do is concatenate them
together and run PGP on the big file. To encrypt a binary, use this command:
pgp -a picture.gif
or if the TextMode option is set to ON:
pgp -a picture.gif +textmode=off
You may know that there is a difference between a carriage return (CR) and a
linefeed (LF). This is principal to the canonical text form. In MS-DOS ASCII
files, each line ends with both a CR and an LF. On UNIX, each line ends with a
CR, and on a Mac, each line ends with an LF. It's a sad fact of life. So when
sending email, use the -t arg, for text form. If you send email
and usenet principally, find in the config.txt file the TextMode
option, and set it to on. Then when you wish NOT to use text mode, as when
sending a binary, you must add +textmode=off to the end of the PGP
command. This converts the text to the canonical form, which happens to have
both a CR and LF, and on the receiving end, PGP will know to take out either a
CR, an LF, or neither, whichever is appropriate to the receiver's platform.
Signing keys is not to be confused with the signatures which I have discussed. To sign a key is to give your certification that the public key you have signed comes from the person who lays claim to it. This should not be taken lightly. To sign a key says to the world that you are absolutely CERTAIN, beyond all doubt, that you can not be persuaded otherwise, that Bob Williams' key is really his key. You usually should not sign a key unless the person in question gives it to you on disk. It has been known to happen - a key-signing party, where a group of PGP users (sounds like a drug party, I know) get together and sign each other's keys. It's a good way to get a lot of keys signed quickly. So what's the point? If I sign Bob's key, and you download Bob's message, and his signature checks out, but you're still not convinced, then check the signatures on his public key, like this:
pgp -kvv williams
This will show you how many signatures are on Bob's key. It shows the keyID of the signators, and, if you have a signator's (for example, me) public key as well, shows who they are. But if you don't have the key of the corresponding keyID (an 8-digit hex number) then, well, you're out of luck. If you do have my public key, you see that I have signed Bob's key, and thus you know that you can fully trust his key, because you trust me. BUT, if you see on Neil's key that Bob has signed it, then you have NO REASON to trust Neil's key, because you don't trust Bob, only his key. The ideal state is a globe-encircling "web of trust" in which every key in existence has been signed by at least one person that you know, that I know, that everyone knows. It doesn't have to be the same person, just everyone has a person whom they trust fully. When signing a key, keep in mind how much can be tampered with. Do you know that this is a key which was created by Bob? Could someone else have made a key in Bob's name and then, being sneaky, prepared to intercept Bob's email encrypted with that key? You never know. Not to make you paranoid, but you DO have to be careful. You can't anticipate everything, though. (If this worries you excessively, then I will tell you this: email, at this point, is just not the securest of ways to do things. Sorry.)
You may, if you are an Astute Thinker, have thought about this already; "How do I transfer my keys?" You must extract your public key into a file, like so:
pgp -kxa drosoff
The k is for key, x is for eXtract, and
a is for ASCII-armor. The only time when you wouldn't use
armoring is if you want to store a copy of your key on a floppy or another
machine. Of course, you could if you wanted to. PGP will ask you for a file
name. You can then sign the file, pgp -sat keyfile.asc with
t meaning text, read it into your mailer program, and send it
away. Where to send it? Keyservers
abound, and there is also a newsgroup solely for circulation of keys,
alt.security.keydist. While I'm at it,
here is the PGP
frequently discussed resource page.
To add keys to your keyring, you must get the key in an ASCII-armored keyfile, which usually will end in an .asc. You can get these from your friends personally, finger, email, web pages, alt.security.keydist or the keyservers previously mentioned. Once you have it, simply type
pgp keyfile.asc
follow the directions, and that's all there is to that. You may want to verify before you actually use the key, if you're of the especially paranoid lot.
Verifying keys is the part of PGP that gives me the biggest headache. Why verify? To make sure that the person you think gave you the key really did. If you try to use an unverified, or uncertified key, PGP will beep to alert you of this discrepancy. However, you can still go ahead and use the key if you want to.
-ks mary arg.
Note: PGP will ask you how much you trust this person. Keep in
mind, just because you trust a person's key doesn't mean you necessarily trust
the person. But if you do, then you can certify that person as an introducer
of other keys. For example, you sign your good friend Mary's key and certify her
as an introducer. Mary, in person, gives you a copy of Bob's key, which she
knows to be good and has signed. This means that PGP automatically certifies
Bob's key, and you can sign it in turn. However, if you have never met Bob, then
you will not want to certify him.pgp -kvc williams. This will show you a short version
of the key, called a fingerprint, which you can read over the phone to Bob as he
compares with his key fingerprint. If you have the right key, you can sign it,
and, according to your judgment, certify Bob as an introducer.These are the ways listed in PGP documentation file pgpdoc1.txt. You may be able to think of other ways. Send them to me if you do. To verify my key, which is available here, you can note the fingerprint. I include it with the key file. Directions accompany.
You must be in the U.S. to get PGP from MIT. MIT PGP 2.6.2 is the standard in the U.S. There is an international version in Norway that anyone can get. (If you can't find what you need there, try here. (FTP capability required.)) Keep in mind that unless your country has nothing against strong crypto, you can get in BIG trouble. I wouldn't get PGP if I were in France or Iraq. Why the difference? That's because the author, Zimmermann, is being pestered by the government because PGP falls into a category of munitions the export of which is prohibitable by law. Of course, right after he wrote PGP, his friend put it on the 'Net, which resulted in a giant lawsuit from the U.S. government, which has since been dropped. So to get PGP (in the U.S.), head to How safe is PGP?
PGP is so safe, the U.S. government threw a fit, presumably because they won't know what's in the email -- drug trades, tax evasion, whatever. PGP is a "military-grade" encryption algorithm -- now available to the masses. Here's what NetGuide has to say about PGP's uncrackable algorithms:
There are special programs to crack encrypted e-mail, but PGP is designed so that, by some estimates, a computer using 1 billion chips, each far more powerful than any that exist today, would require 10 trillion years to try all possible combinations generated by just one of the encryption algorithms used in PGP. There are other encryption programs available, but as Zimmermann asks rhetorically, "Which has the government most upset?"
PGP is just the best there is. The best part of it is, (besides being free, of course) that when you send your buddy your public key, it doesn't matter who intercepts that email and reads it. Because the only thing a public key does is encrypt mail, not decrypt it. Only your secret key decrypts mail, and you shouldn't be sending it out.
So much for the basics of PGP. Thanks for reading this. If you are interesting, follow the links to get PGP or to learn more elsewhere in this page.
I like to think that this is a good reference, but if you didn't get the information you need, try this page. The newsgroup alt.security.pgp has a detailed FAQ as well. Derek Atkins' FAQ is available, too; it deals with more technical issues, rather than usage.
In general, args with a -k are (k)ey commands, anything else is an encrypt command. The -k commands are easy to remember; -kg for Generate, -ka for Add, -kr for Remove, -kv for View, -kx for eXtract. Encrypt ones are easy too: -c for Conventional, -e for Encrypt, -s for Signature, -a for Armor (PGP-ese for email format), -t for ... only a signaTure, I guess. Except in -ka, -a ALWAYS means armor.
Congratulations, you made it! You are thus certified as smarter than the average, and I am very proud of you for actually comprehending this page. You must have been in the top 5% of your class at college. Before you continue, I would like to know if you have any remaining questions which I have not answered. If so, please send them to me at [email protected]. I am compiling a small, unofficial FAQ for this page and need your input. Thank you very much.
You might want to also look at:
Last Modified 16 March 1997 by David Rosoff.