- The History and Philosophy of PGP.
- Overview of PGP.
- Starting with PGP.
- Generate a Secret Key/Public Key Pair.
- Sign your own key.
- Adjust the file
- Extract your public key.
- Add a key to your public key ring.
- Encrypt a file.
- Decrypt a file.
- Miscellaneous PGP commands.
- Publish your public key(s)
- Things to do with keys.
- So how do I know this key is good?
- Who Do I trust?
- When to use PGP.
- Protect your right to use encryption.
In the beginning, nobody needed encryption, because no one could write! Then, after many years of struggle, writing was invented! But there was still no problem, because only the rulers and their trusted servants could read or write. But, as time went on, more and more people learned to read, and there began to be a problem with written communications, in that if someone hostile intercepted a written document, they could read it!
This began a war between the people trying to find ever more complicated, neat ways of scrambling messages and the people trying to figure out ways of descrambling them. Sometimes the people scrambling messages would win, and sometimes the people descrambling messages would win. As time went on, this war over ciphers became intertwined with regular wars, and things got interesting! In spite of cryptography's use in wars, cryptography was invented by civilians. And it was used by civilians through out its history.
Anyhow, the first ciphers were single key or conventional ciphers. In single key ciphers, there is one key that must be used by both the sender to encrypt, and by the recipient to decrypt. The message can be decrypted by anyone who possess this key. This leads to the key distribution problem. There must be some way to insure that both the sender and the recipient have the same key. Care must be taken so that unwanted parties do not posses this key. It is necessary to have some kind of secure channel to accomplish this. The problem with secure channels is that they are difficult to establish and that people are always trying to compromise them.
Then Rivest, Shamir, and Aldeman invented Public Key Cryptography and the algorithm that bears their name, RSA. The RSA algorithm is based on the mathematics of exponentiation.
In this scheme, there are two keys, an encryption or public key and a decryption or secret key. The Recipient creates both keys. The encryption key is published. The decryption key is kept secret. Thus, anyone can encrypt and send a message to the recipient, but only the recipient can decrypt. This encryption scheme solves the key distribution problem, since the only key that the sender needs can be published without compromising the messages. It can be sent via any unsecured channel.
Now, from your point of view of as a user of PGP, PGP behaves as if it were a Public Key Encryption program. A you create a secret/public key pair and publishes the public key. But internally, PGP is a hybrid encryption program. When PGP encrypts a file, it creates a random conventional encryption key. It sends that key to the recipient using a header block that is encrypted using RSA public key encryption. Thus RSA serves as the secure channel which is used to transmit a conventional key, solving the key distribution problem. The bulk of the message is encrypted using a conventional cipher, IDEA. PGP uses this scheme because RSA encryption is very slow, so that if the whole message were encrypted with RSA then PGP would be too slow. IDEA is thought to be a stronger encryption method than RSA so this scheme does not weaken PGP.
Now, PGP stores keys in keyrings.
Usually, public keys are stored in a file called
and secret keys are stored in a file called
How does PGP help you keep your secret keys secret? RSA secret and public keys must be hundreds of bits long and they are must be chosen randomly. This presents a problem. If PGP were to ask you, a human being, to remember your public key, it would be incontinent, because most human beings do not remember long strings of binary information well. You might write it down. This would be bad, because someone might do a black bag job on you. A black bag job is when a practical cryptoanalyst comes to your house when your are not there with a bunch of locksmithing tools in his black bag. He comes away with your secret key in his black bag. The other alternative would be to store your secret key in a computer file. But this risks someone doing a black bag job on your computer. PGP solves this dilemma by storing both your public and secret keys in computer files called keyrings. But, it stores your secret key encrypted with conventional encryption. Your secret key will be protected with a pass phrase which you must specify every time you wish to use your secret key. (When you decrypt a message or sign a message.) Hopefully, you will choose your pass phrase so that it will be easy for you, as a human being, to remember it.
PGP scrunches your pass phrase to a 128 bit cryptographic checksum, using an algorithm called MD5. (English has a entropy of about 1 bit per character, so if you use a pass phrase 128 characters long, then all values for the checksum will be equally possible.) This checksum is used as a conventional key to encrypt or decrypt your secret key, using IDEA.
The upshot of all this is that your secret key is stored on a file on your disk. Thus your disk must be carefully backed up. The secret key is encrypted, so that you must specify a pass phrase anytime you wish to perform an action that uses your secret key. Thus you will be asked for your pass phrase when you wish decrypt a message, or when you wish to sign a message. You should choose your pass phrase so that you can remember it, but no one else can guess it.
PGP can authenticate or sign messages. You can create digital signatures. A digital signature is additional information that tends to show that a given document really came from a given person. PGP can check digital signatures to check if a given document for tampering. How does PGP authenticate a message?
A PGP digital signature shows that the person who signed the document had access to the PGP secret key and the pass phrase for the key indicated by the signature and that the document has not been modified since it was signed. This is different than hand writing signature authentication, which ultimately depends on the nervous system of the signer.
PGP has no menus. there are no mouse buttons to click. PGP will not paint a fancy picture for you to look at and it will not cause sound to come out of your computer. PGP is a unix style command line program. The direct way to use PGP is to enter a PGP command. This command will typically include computer filenames, key identifiers and options. Options begin with the "-" character followed by a string of incomprehensible letters. (Except for the Mackintosh version of PGP. Hey, I do not know anything about the Macintrash or the Macintrash version of PGP, but you might try MacPGP and AppleScript FAQ.)
However, the command pgp -h displays all the information you need to accomplish most PGP tasks, provided you understand PGP terminology and philosophy.
Read the documentation that comes with PGP. There are subtle problems that you can get yourselves into if you do not. This document attempts to give you the background to understand the documentation.
There are six books on PGP.
- PGP Pretty Good Privacy by Simson Garfinkel
- Protect Your Privacy A Guide for PGP users by William Stallings
- E-MAIL SECURITY How to keep Your Electronic Messages Private by Bruce Schneier
- The Computer Privacy Handbook by André Bacard
- The Official PGP User's Guide by Philip R. Zimmermann
- PGP Companion for Windows The offical Guide to WinPGP by Peter Kent
There are a number of Web pages devoted to PGP and Cryptography.
- Where to Get PGP
- CUI W3 Catalog
- The World-Wide Web Virtual Library: Cryptography, PGP, and Your Privacy
- Matt Thomlinson / firstname.lastname@example.org / Cypherpunks Topics, Toad.Com
- alt.security.pgp FAQ (Introduction)
- Pretty Good Privacy -- Where to get it.
- PGP 2.6.2 hypertext documentation
- PGP User's Guide, Volume I: Essential Topics
- PGP User's Guide, Volume II: Special Topics
- File Formats Used by PGP 2.6 (22 May 94)
- The Cypherpunks Home Page
- PGP in a Nutshell
- PGP Startup Guide
- Ståle Schumacher's PGP Web page.
There are a number of PGP frontend programs that give PGP a menu oriented interface.
- PGP-Related Utilities and Services
- Other People's PGP addons
- Index of ftp.informatik.uni-hamburg.de:/pub/virus/crypt/pgp/tools/
- Index of ftp.ox.ac.uk:/pub/crypto/pgp/
There are two separate problems that encryption programs have in dealing with text. PGP has two separate solutions to these problems. It is important that these problems and their solutions not be confused. If the solution to one problem is used when the other solution is required, the results will be bad.
Ordinarily, a well encrypted file is not mailable.
The encrypted file usually uses characters that most
mail programs will not accept. Since line terminators
occur essentially randomly in the encrypted file, lines
can easily be too long for most mail programs.
PGP solves this problem with the
This causes PGP to use the ascii radix-64 armor
The resulting output limits the characters used to a set of
characters that mail programs will accept. It creates lines
a reasonable size. Thus the output file should be mailable.
PGP is programmed to accept such files, reversing the radix-64
format before decrypting. The
-a option can be used
when signing a file as well. This causes the signed file
to be in the radix-64 format. Using
results in output that is about 30% larger.
-a option can be specified by itself, without
requesting encryption or authentication. In this case, PGP
is being used as a superior uuencode/uudecode.
Different Operating systems represent text in different ways.
For example, different end of line characters are used.
The UNIX operating system uses linefeed characters to end lines,
but the MSDOS program loader uses the carriage return linefeed
combination to end lines. The Macintrash operating system is
said to use carriage returns to separate lines. These differences
mean that text files must be converted, when they move between
operating systems. If this conversion is not done, then the files
will not display or print properly.
This need for text file conversion, is why the FTP
(file transfer program)
needs to have binary and ascii modes, when it moves files
between operating systems.
Now when PGP is asked to
encrypt a plaintext file on one operating system and decrypt it
on another, then the PGP system as a whole is being asked to move
a text file between operating systems.
The same considerations apply when signing text files on one
operating system and removing the signature on another.
should be specified when
encrypting or signing a text file. This will ensure that
the text file conversion is done correctly. The
should not be used if the file contains binary data, such as
executable, some word processor files, and many data files.
- Fred wishes to encrypt a spreadsheet file (
.WKS) and put it on a floppy and mail it to his financial advisor.
Since the file is not being sent through e-mail, the
-aoption is not needed. Since the file contains binary data, the
-toption should not be used.
- At the last minute, Fred finds that his financial advisor has
an e-mail address and decides to e-mail the file.
Since the file is going to be e-mailed, the
-aoption should be specified. The original file still contains binary data, so the
-toption should not be specified.
- A huge text file needs to be moved to the accounting department's
computer. For security reasons, this computer is not connected
to any networks, so the file will be moved on a floppy
-toption should be used because the original file is text. The
-aoption is not needed, and should not be used so the resulting file has a better chance of fitting on one floppy.
- Fred wishes to e-mail an encrypted love-letter to his girl friend.
Since the plaintext is text, the
-tshould be used. Since the output from PGP must go through e-mail, the
-aoption should also be used.
The first thing to do is to create a directory for PGP and its files to live in. Unpack the distribution files to this directory. (If you are using PKUNZIP under the MSDOS program loader, be sure to use the "-d" switch.)
Modify the PGPPATH and PATH variables.
PATH should point to the directory where the PGP
executable exists. PGPPATH should point to the directory
where the PGP data files are. The procedure for doing this
depends on your operating system and should be documented
the documentation that comes with your PGP distribution.
When using the MSDOS program loader, you would modify the
AUTOEXEC.BAT. when using OS/2 the file
CONFIG.SYS should be modified.
The first thing you want to do after installing
PGP is to generate keys using the
command. This will allow messages to encrypted for you, and
it will allow you to sign messages.
PGP will ask you for a key size. Unless your computer is a klunker, choose 1024 bits. (If your computer is fast, and you are extremely paranoid about the computers in the NSA's basement, you may want to create an additional key with 2047 bits, if you have PGP 2.6. But you would not want to make that key your primary key, because not all versions of PGP support keys with more than 1024 bits.)
Choose the key identifier for the key. From the point of view of PGP, the key identifier can be any string of characters, but to use the key identifier with mail programs, follow the convention:
First Last <email@example.com>Your internet mail address should be enclosed by the <> characters.
Choose your pass phrase according to the following rules:
- Choose a pass phrase you can remember.
- Choose a pass phrase that can not be guessed.
- at least 128 characters.
- can not be deduced from your personal history.
- is not found in literature or popular culture.
- Do not use your pass phrase for any other function.
PGP needs to make itself unpredictable, so that a hostile cryptanalist can not predict what it is doing. To do this it is necessary for PGP to get some random numbers . It is difficult to get random numbers in a computer program, because computers and operating systems are designed to be predictable. To create random numbers, PGP will ask you to type some text on your computer. PGP creates the random numbers by measuring the timing of your keystrokes. It does not matter what you type, but do not use the autorepeat feature of your keyboard if it has one.
You should always sign your own public key. The following command will sign the key my-key-identifier:
pgp -ks my-key-identifier -u my-key-identifier
You may wish to adjust the file
to conform to your personal preferences. You can study
PGPDOC2.TXT that comes with your PGP
distribution to know how to do this. If you have more than
one secret key, you may wish to set the configuration variable
MYNAME to be your default secret key.
To allow others to send you encrypted messages, you must give them your public key. To do this, you must extract your public key to a file:e-mail, you will want to add the
pgp -kxa my-identifier file
When someone sends you their public key, you can add it to your public key ring.
pgp -ka file
After you have added a public key to your keyring, you can encrypt a message using that key.
pgp -e file key-identifier
To decrypt a file, use the simple:
pgp ciphertextfileThis command will also check digital signatures if any. To display a file a screenful at a time use the -m option.
PGP can sign file creating digital signatures:
pgp -s textfile -u my-key-identifier
Authentication can be combined with encryption, creating an encrypted, signed file.
pgp -es textfile their-key-identifier -u my-key-identifierThis will create a file that the owner of their-key-identifier can decrypt and signed by my-key-identifier. The encryption is done after the signature, so that a person who can not decrypt the file can not tell who signed the file.
Suppose you wish to post a message to a USENET newsgroup. You want to sign the message, so that people can check its signature with PGP, but you want the text of the message to be readable by people that do not have PGP. You want to create a clear signed message:
pgp +clearsig=on -sat textfile -u my-key-identifier
Be careful not to enter clear signed messages into FIDONET systems without the permission of the sysop. Most of FIDONET is extremely authoritarian, and does not allow encrypted or signed messages. Although we can laugh at the rigid orthodoxy of FIDONET, we should respect the property rights of the sysops.
You can create a signature certificate in a separate file:
pgp -sb textfile -u your-key-identifierThese certificates can be checked by specifying both the certificate and the original file to PGP.
pgp certificate-file original-fileDetached certificates can be used to sign an executable file, without modifying the file so that it remains executable.
Special PGP commands that do not really fit anywhere.
When a file is deleted under most operating systems, the data in the file is not necessarily destroyed. Usually, the directory entry that points to the blocks of the file is removed and the blocks of the file are returned to the disk's free space. It is possible that someone could recover the data of the file. There are the famous "undelete" programs that function under the MSDOS program loader. When PGP wipes a file, it overwrites the data so that the data is DEAD, DEAD, DEAD and can never be recovered.
pgp -w datafile
The -w option can be used when encrypting a file to wipeout the plaintext after encrypting.
pgp -esatw plaintextfile their-key-identifier -u my-key-identifier
If your operating system supports pipes, you can cause PGP to take its input or output from a pipe by specifying the -f option. (If you do not know what a pipe is, do not worry about it. You can get along without pipes, and perhaps your operating system does not support them.)
To cause the decrypted file to have its original filename,
pgp -p ciphertextfile
If you are encrypting a file to your self, you can avoid fooling around with keyrings by using conventional encryption:
pgp -c plaintextfilePGP will ask for a pass phrase to use as a key. The pass phrase will be required to decrypt the file.
You need to publish your public keys, so that
people who have not previously contacted you can
send you encrypted messages and check your signatures.
To publish your public keys, you should use a
PGP public keyserver
. These key servers are used by sending them e-mail
commands. These commands are described by the file
KEYSERV.DOC that comes with the PGP distribution.
To publish your public key, first extract the key as a radix-64 file.
pgp -kxa my-key-identifier filee-mail the resulting file to a public key server with subject "add". It is only necessary to send your public key to one public key server. They are like small town gossips. They all talk to each other. To tell one is to tell them all.
To get somebody else's public key from a public key server, send a null e-mail message to a server with subject get key-identifier. The mail server will mail you back a radix-64 encoded key file, which you can add to your public keyring.
pgp -ka keyfileThe list of keyservers changes from time to time.
The public key servers make no checks to insure that a given keys in its database actually came from the person indicated by the key identifier. This determination is your responsibility.
pgp -kr key-identifier
You can revoke keys, declaring that the keys have "gone bad" and should not be used:
pgp -kd key-identifierThis will produce a revocation certificate, which should be sent to the public key servers to declare that the key has gone bad. Remember your pass phrase! You can not revoke a key without the pass phrase.
You can edit keys:
pgp -ke key-identifierThis will allow you to edit the pass phrase or key-identifier of a secret key, and it will allow you to change the trust parameters of a public key. You might want to change your key identifier, when your name, or your internet mail address changes. Whenever you change a key identifier, you should always sign your new public key.
pgp -ks my-key-identifier -u my-key-identifier
How do we know that a given key actually belongs to the person indicated? A fraudulent key can be created to trick us into accepting bad signatures. It could be used to trick us into encrypting a message that the wrong person can decrypt. It is possible to forge an e-mail message, so we can not necessarily trust that the e-mail message that brought us a public key was not fraudulent. As we have seen, the public keys servers do not check that the keys stored in their databases are correct.
The first and most basic way of checking a public
key is to contact the owner directly. You could
call the owner on the phone, and ask the owner if
the key you have really belongs to him. Then if you
recognized him by voice, you could be sure you had the right
key. But how would you know that you and the key owner were
talking about the same key? He could have a key with
This will cause pgp to print a fingerprint that looks
Key signatures are used to transfer the knowledge of the
"goodness" of a given key from one person to another.
Let us do a thought experiment. Suppose that Judy
has received a key from Fred through e-mail, and
she needs to verify that it is really Fred's key.
She does not know how to contact Fred directly, but
she has a friend, Sally, who does. She already has
Sally's valid key. She (Judy) could get Sally to send
her a PGP signed message like this:
Judy can run this message through PGP to verify
that it really came from Sally. She can check the fingerprint
against the fingerprint she has. If the fingerprints
match, and she trusts Sally, then she can be sure that
the key really is Fred's key.
It is never necessary to actually send or create messages like the above.
PGP supports the same functionally through the concept of
"Key signatures". When one signs a key, one is essentially creating
a message like the above, and attaching it to the key itself
on the key ring! Then, when a key is extracted
from a keyring, and
sent to someone else, and added to another keyring, the
"key signature" goes with it! Thus key signatures propagate
from user to user in the same way that keys do. To sign a key:
Whenever you sign a key, you should re-send the key to the
public key servers so that other PGP
users can use the signature to determine the validity of the key.
You can view the signatures that are attached to a key
When PGP uses a key for encryption or signing,
it determines if in PGP's opinion, the key can be trusted.
If PGP does not trust the key, it will print an
message warning you that the key is not to be trusted. You can
tell PGP to use the key anyway. PGP
determines trust on the basis of signatures from trusted keys.
When you add a key to your public keyring
you are asked if the key can be trusted to introduce other
keys. If a PGP notes a signature from a trusted key, it
tends to trust the key bearing the signature. You can
change the trust parameters on a key using the -ke
Furthermore, you should not expect other people to trust your
inferences. If you infer that a given key is good
on the basis of key signatures, you should not sign that
key. You should only sign
a key when you know of your own
personal knowledge that a key is valid.
Always, use PGP when the person you are corresponding
with has it. This establishes that you are a regular PGP
user. It asserts your right to use PGP. If you make it
a habit to always use PGP then you will not draw attention
to any sensitive messages you might wish to send.
Use conventional encryption, the -c
option, when you are encrypting files to yourself. This
avoids the RSA algorithm and is slightly stronger.
It avoids the necessity to muck around with keyrings.
Every PGP encrypted file contains header
information that identifies it as a PGP
encrypted file, even to someone who can not decrypt it.
If you wish it to remain a open question if your encrypted
file is in fact encrypted, you should use a raw conventional or
symmetric cipher. You can remove the PGP headers
from an conventionaly encrypted PGP using a program
There have been recent rumblings about government plans
to outlaw private strong encryption.
I believe in the right to use encryption for a number of
pgp -kvc key-identifier
Key ring: 'E:\PGPDATA\pubring.pgp', looking for user ID "paul.elliott".
Type bits/keyID Date User ID
pub 1024/D4849879 1994/01/29 Paul Elliott (standard 1024 bit key)
The key fingerprint of a given key is designed to be unique. If
two people get the same key fingerprint for a given key, then they
know that they are dealing with the same key. Key fingerprints
can be used to verify the validity of keys over the phone.
We now pass on to more indirect methods of checking the validity
-----BEGIN PGP SIGNED MESSAGE-----
I know of my own personal knowledge that the key
with key fingerprint:
F6 C7 33 D8 64 07 46 D7 FD 67 53 80 CE 7E 0B C8
Really does belong to Fred!
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
pgp -ks the_key_id_you_are_signing -u the_key_doing_the_signing
pgp -kvv key_identifier
pgp -ke key_identifier
This will cause pgp to print a fingerprint that looks like this:
Key signatures are used to transfer the knowledge of the "goodness" of a given key from one person to another. Let us do a thought experiment. Suppose that Judy has received a key from Fred through e-mail, and she needs to verify that it is really Fred's key. She does not know how to contact Fred directly, but she has a friend, Sally, who does. She already has Sally's valid key. She (Judy) could get Sally to send her a PGP signed message like this:
Judy can run this message through PGP to verify that it really came from Sally. She can check the fingerprint against the fingerprint she has. If the fingerprints match, and she trusts Sally, then she can be sure that the key really is Fred's key.
It is never necessary to actually send or create messages like the above. PGP supports the same functionally through the concept of "Key signatures". When one signs a key, one is essentially creating a message like the above, and attaching it to the key itself on the key ring! Then, when a key is extracted from a keyring, and sent to someone else, and added to another keyring, the "key signature" goes with it! Thus key signatures propagate from user to user in the same way that keys do. To sign a key:
Whenever you sign a key, you should re-send the key to the
public key servers so that other PGP
users can use the signature to determine the validity of the key.
You can view the signatures that are attached to a key
When PGP uses a key for encryption or signing, it determines if in PGP's opinion, the key can be trusted. If PGP does not trust the key, it will print an message warning you that the key is not to be trusted. You can tell PGP to use the key anyway. PGP determines trust on the basis of signatures from trusted keys. When you add a key to your public keyring you are asked if the key can be trusted to introduce other keys. If a PGP notes a signature from a trusted key, it tends to trust the key bearing the signature. You can change the trust parameters on a key using the -ke option.
Furthermore, you should not expect other people to trust your inferences. If you infer that a given key is good on the basis of key signatures, you should not sign that key. You should only sign a key when you know of your own personal knowledge that a key is valid.
Always, use PGP when the person you are corresponding with has it. This establishes that you are a regular PGP user. It asserts your right to use PGP. If you make it a habit to always use PGP then you will not draw attention to any sensitive messages you might wish to send.
Use conventional encryption, the -c option, when you are encrypting files to yourself. This avoids the RSA algorithm and is slightly stronger. It avoids the necessity to muck around with keyrings.
Every PGP encrypted file contains header information that identifies it as a PGP encrypted file, even to someone who can not decrypt it. If you wish it to remain a open question if your encrypted file is in fact encrypted, you should use a raw conventional or symmetric cipher. You can remove the PGP headers from an conventionaly encrypted PGP using a program called stealth.
There have been recent rumblings about government plans to outlaw private strong encryption. I believe in the right to use encryption for a number of reasons: