PGP: The key to your heart

  • ASCII armor files can get fairly large, and may be too large for some transports. By default, PGP limits a single ASCII armor file to 720 lines, breaking up large files into several armored transports. You can change the maximum armor file size in the PGP configuration file, usually kept in ~/.pgp/config.txt.
  • Encrypting the file required only the recipient's public key, and no key information of your own. As a result, only the recipient can decrypt the file. You created it, but only the holder of the private key can unlock the encryption done with his or her public key. You can encrypt a file for multiple users by specifying them all on the command line:
    <font face="Courier">
    huey% pgp -eat pepe marie sven yaya
    Putting your own user ID in the list, or enabling the
    <font face="Courier">ENCRYPTTOSELF</font>
    option in the configuration file, ensures that you'll be able to decrypt a file that you created.
  • Your crypto-cognoscenti friends will quickly point out that PGP uses both private and public key encryption. They're right. PGP generates a random session key for each invocation. The session key is encrypted via a public key algorithm, so that it can be unlocked on the other end. The data, however, is encrypted using a private key algorithm. The session key and encrypted data get tucked into the PGP file. When Pepe decrypts the file, he first extracts the session key using the private half of his public key pair, and uses that key to unwind the encryption used on the message body. Public key encryption is simply too slow -- nearly 1,000 times slower than private key. A side effect of the public/private key combination is that subsequent encryption attempts on the same file produce different output files -- each one is encrypted with a different session key, and therefore each has different contents.

Hiding your privates: key management

Now that you've seen how the public and private parts of a key are used, it's time to generate your own and collect those of your friends. Keys are kept on key rings, similar in concept to physical key rings. By default, there are two key rings -- pubring.pgp and secring.pgp -- for your collection of public keys and your own private keys. You can add other rings for your co-workers, friends, and other circles of data exchangers as needed. Key rings live in ~/.pgp, along with the configuration file.

The first step is to create a unique key pair. This will add your own key to both the public and private key rings:

<font face="Courier">
huey% pgp -kg
Pick your RSA key size:
1)   512 bits- Low commercial grade, fast but less secure
2)   768 bits- High commercial grade, medium speed, good security
3)  1024 bits- "Military" grade, slow, highest security
Choose 1, 2, or 3, or enter desired number of bits: 3
Generating an RSA key with a 1024-bit modulus.

You need a user ID for your public key.  The desired form for this
user ID is your name, followed by your E-mail address enclosed in
<angle brackets>, if you have an E-mail address.
For example:  John Q. Smith <>
Enter a user ID for your public key: 
Hal L. Stern <>

You need a pass phrase to protect your RSA secret key.
Your pass phrase can be any sentence or phrase and may have many
words, spaces, punctuation, or any other printable characters.

Enter pass phrase: 
Enter same pass phrase again: 

The first thing you need to specify is the length of the key you want. There are few reasons to use less than 1,024 bits, given the speed of most machines you'll be using for encryption. Key generation is a slow process, due to the large numbers being multiplied and reduced -- it takes about 40 seconds to create a 1,024-bit key on a SPARCstation 10. PGP then asks you for your user ID, which is typically your full name followed by your e-mail address in brackets. In previous examples requiring a user ID, the string supplied is used to search through the public key ring for a match in the user ID field. When we chose pepe as a user ID, we picked up the public key for

<font face="Courier">Pepe 

Finally, you'll need to specify a pass phrase for your private key. This pass phrase is what protects your private key from exposure on your local machine. If you were wondering how you were supposed to remember a 1,024 bit key, the short answer is you don't. The private key is encrypted using your pass phrase, and the encrypted string is added to the key ring. Key point: don't forget your pass phrase, or you'll have to create new public keys and go through the distribution process again. Similarly, don't choose a trivial pass phrase, or interested parties will crack open your private key and use it to decipher your incoming messages.

Now that you have created a key, you can give it to friends and family. The easiest way to do this is to extract the key from your public key ring:

<font face="Courier">
huey% pgp -kx stern mykey

This pulls the key for user ID stern out of the public key ring, and writes into mykey.pgp (the extension is filled in for you by PGP). Put this file on a floppy and give a copy to anyone wishing to send you encrypted files or mail. Hopefully, they'll exchange their public keys with you as well so you can reciprocate. If you want to send the public key via e-mail, extract it in ASCII armor:

<font face="Courier">
huey% pgp -kxaf stern mykey | mail 

If you take a look at the key file, it's merely the public part of your key represented in ASCII, with an ASCII PGP wrapper around it:

<font face="Courier">
Version: 2.6.2


When Pepe gets the file, he saves the message in a file and adds the public key to his key ring:

<font face="Courier">
huey% pgp -ka hiskey.asc

PGP also has several options for managing keys, allowing you to edit your user name or pass phrase and to check (examine) keys in any ring.

Personal exchange gives you a high degree of confidence in the keys. Unless you have a malicious identical twin, someone receiving a floppy from you can rest assured that it contains your valid public key. Trading floppies in coffee shops is nice, but it's unlikely you'll be able to personally meet people from all over the world. If you need to rely on e-mail distribution, you need some additional guarantees that the keys you're getting are valid.

Practically safe hex: trust and validity

PGP key management is built on the principles of trust and validity. Before adding a key to your public key ring, you want to make sure that it's not from someone posing as the sender. If I want to intercept mail going between you and your manager, I can simply pose as your manager and send you a message saying "Here is my new public key, please add it to your PGP public key ring." Then as I watch messages go by, I can decrypt them using the corresponding bogus private key. This may work once or twice, until your boss complains that she can no longer decrypt your messages encrypted with PGP.

The questions you need to answer when adding a key are:

  1. Is this key valid? Is it really from the person who claims to have created it?
  2. Can I trust anyone who tells me this key is valid? I may give you a key for a mutual friend, and you decide to take my word that the key is authentic. But the further you go in the friend-of-a-friend food chain, the less you tend to trust people.

Would you loan your car to my best friend's friend? Even though individual relationships are built on trust, you shouldn't feel comfortable extending trust to an arbitrary degree of separation.

Trust and validity are established through key certification, or signatures on keys, and key fingerprints. A fingerprint is simply a 128-bit checksum of the key. View the fingerprint of a key using the

<font face="Courier">-kvc</font>
option to PGP:

<font face="Courier">
huey% pgp -kvc pubring.pgp
Key ring: '/home/stern/.pgp/pubring.pgp'
Type bits/keyID    Date       User ID
pub  1024/CA1D1839 1996/01/25 Hal L. Stern <>
Key fingerprint =  E2 C4 A9 6C 5C D1 93 93  C3 0D D6 34 24 D3 55 7F 
1 matching key found.

When I send you my key, I can also send you its fingerprint via another channel: over the phone, on my Web page, or on my business card. Compare the fingerprint generated by PGP while adding the key to the one you collected out of band, and you can determine if the key has been tampered with in transit. If you feel comfortable with either the key distribution or the fingerprint distribution, then you should feel comfortable adding the key to your public key ring.

When you add a key, PGP checks to see if it has been certified by the presence of any digital signatures. If there are no signatures, PGP gives you the option of certifying the key by signing it. If you do, you are making an explicit guarantee that the key is valid; if you later distribute that public key to a third party, he or she will see a certified key with your signature on it.

When PGP is given a certified key, it asks if you trust the signer to introduce new keys to you. If not, then the key will not be certified in your key ring. When you add a key, you attribute a certain level of trust to the person; people you trust can certify keys to be added to your key ring. If you get a key from an unknown person, but someone you trust has certified it, PGP will assume that you will accept the key as well. The bottom line, again, is to be careful with delegating trust and accepting keys on blind faith. The key distribution and certification chapter in Garfinkel's book covers this material with some outstanding examples.

One-on-one key distribution is slow, and not always convenient. What do you do when you need someone's public key and can't wait for them to send it to you? Several public key servers are available, such as the MIT Web server ( There are also e-mail-based public key servers, including and Send mail with a subject of INDEX and you'll get a key directory; extract a single key with a GET. The MGET command fetches multiple keys, using regular expression syntax for the user names, and ADD submits your key to the server for public distribution.

King George should be able to read this: digital signatures

All of the PGP examples discussed to this point let you safely exchange keys and data with groups of users on a one-to-one or one-to-few basis. How do we solve the broadcast problem outlined in the introduction, where we want to check the authenticity of a message sent to an alias? In more general terms, how do we verify the identity of any message's sender? Having your public key means I can send you a private message without fear of interception. But how do you know the message came from me, and not someone pretending to be me who happened to have your public key? Digital signatures fill the technology gap.

The basis for digital signatures is a keyed hash, or a checksum that has been encrypted for verification. The most common keyed hash, and the one used by PGP, is called Message Digest 5 (MD5), created by Ronald Rivest of RSA fame. MD5 takes a message of arbitrary length and distills it into a 128-bit checksum. The algorithm is highly sensitive to minute changes in the input, so changing a single bit is enough to generate a completely different checksum. The possibility of MD5 collisions exists, that is, two messages that produce the same 128-bit hash value. However, the probability of encountering two messages with the same MD5 hash value is exceptionally low -- there are 2^128 hash values produced, or about 3 x 10^38. The number of MD5 output values is far larger than the number of documents, messages, and e-mails sent in any person's lifetime. There are some good MD5 tools on the Purdue COAST archive ( MD5 is also one of the functions used in the Tripwire package (, a security tool that creates a hash of selected files and directories on a regular basis to detect intrusion or unwanted modification.

Simply having the MD5 hash value isn't sufficient, because a forger could have modified the message and included the updated MD5 value. The sender needs to authenticate the message digest such that the recipient will know that only the sender could have created it, and that no other user could have modified the value along the way. Turning an MD5 hash value into a digital signature requires using the RSA public key cryptosystem yet again. The public and private key pairs unlock each other, that is, anything encrypted with your public key can only be decrypted with your private key. Conversely, something encrypted with your private key can be decrypted by anyone with your public key. But -- only you could have done the encryption, since your private key is secret and known only to you. Voila! A digital signature that only you can produce, and anyone holding your public key can verify.

PGP's digital signatures work by generating an MD5 digest and encrypting it with your private key. Anyone receiving the file decrypts the signature with your public key, and regenerates the digest to verify the message arrived intact. To sign an encrypted message, add the

<font face="Courier">-s</font>
option to the PGP command line:

<font face="Courier">
huey% pgp -seatf pepe | mail

If you don't specify a secret key, the one added most recently to your private key ring is used. Since you're accessing a private key you need to type in the pass phrase to unlock it, encryption and ASCII armoring takes place as before, with the PGP signature added to the end of the file.

Now let's solve our mail-to-the-world problem. It's possible to sign a file without encrypting it. The signature verifies the identify of the sender and the integrity of the data; it's proof that the message is valid and binding. When the data is going to several hundred people, it's neither useful nor practical to encrypt it. By adding a digital signature you can verify that the message is being sent by an appropriate person. Sign an ASCII message by leaving out the

<font face="Courier">-e</font>

<font face="Courier">
huey% pgp -satf | mail all-company

Looking at the message, and you'll see the plain text followed by a PGP ASCII-encoded signature:

<font face="Courier">

this is a short message file

Version: 2.6.2


Want to prevent spoofing on a grand scale? Feed the all-company alias into a mail handler that verifies the PGP signature, using the sender's return address as a PGP user ID. If the signatures don't match, suspect the mail broadcast as a possible forgery or an inappropriate use of the all-company alias. Implementing this kind of safeguard requires a policy demanding the use of PGP, and educating folks on the ins and outs of PGP signatures. It's a small price to pay, however, for a sudden reduction in junk mail and jokes gone bad that reflect badly on you and your environment. Valentine's Day may break hearts, but you've got to protect the rest of your body, mind, and machine room the rest of the year.

| 1 2 Page 10
ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon