GPG: the Best Free Crypto You Aren't Using, Part II of II

Last month I introduced the GNU Privacy Guard, a free but underutilized implementation of the OpenPGP encryption standards. GnuPG is, as you may know, extremely useful for encrypting and decrypting electronic files, especially e-mail, and for creating and verifying digital signatures.

But alas, by the time I was done explaining the basics of public key cryptography and the Web of Trust, not to mention doing my best to frighten you into signing each other's keys and checking unknown keys for validity, all there was room for in the way of practical examples was some compiling/installing advice and a little tutorial on verifying digitally signed files.

Well, this month is the payoff for the more technically inclined. Let's pick up right where we left off!

Before you encrypt, decrypt or sign anything, you need to build your own public and private keyrings; let's start by generating a GnuPG key pair. This is one of the more interactive gpg functions: the command syntax is simply gpg --gen-key, which triggers a question-and-answer session prior to your keys actually being generated. Listing 1 shows a sample key-generation session (user input in boldface). As you can see, you need to decide several things when generating a key: key type, key length, expiration date and the e-mail address (identity) you wish to associate with the key.

Listing 1. Generating a GnuPG Key Pair

For a general-purpose key pair, choose DSA/ElGamal (option #1). This actually gives you two sets of keys: a DSA key pair that will be used by gpg for signing/verifying and an ElGamal pair that gpg will use for encrypting/decrypting. Don't worry that this will double the amount of keys you need to keep straight: the DSA and ElGamal keys are stored as a single file, as are the two public keys.

If you want to generate a signing-only key pair, choose DSA only (option #2). If you want an encryption-only key pair, choose ElGamal only (option #3).

I recommend against creating a dual-purpose ElGamal key pair, however (option #4). In Applied Cryptography, Bruce Schneier describes a simple attack that can work against schemata that use the same key pair used for both signing and encrypting. This “chosen plaintext” attack is quite literally a textbook example of the danger of using the same key material for both encryption and digital signatures.

Key size is of the utmost importance. The smallest key size supported by GnuPG is 768 bits, but 1,024 is recommended as having the best balance of security and performance. (A longer key is more secure but takes longer to compute and to use; a shorter key is faster to compute and use but is less secure.) Note that when you choose a combined DSA/ElGamal key pair, the DSA key length automatically is set to 1,024 bits, and the key length you're prompted for actually applies to the ElGamal key.

I Thought 128 Bits Was a Large Key Length!

Next you need to think about how long you want this key pair to remain in circulation. On the one hand, if your key never expires, you never have to go to the trouble of generating new key pairs. The disadvantage of this is that if you forget the private key's passphrase and haven't created and kept a revocation certificate (which I'll explain shortly), it will be very difficult to remove the key from any keyservers it's listed on.

On the other hand, if your key expires after some period of time, then you need never worry about obsolete keys sitting around on public keyservers indefinitely: if your e-mail address changes, you decide that your key's length is no longer adequate, or if someone obtains a copy of your private key, you can rest assured that even if for some reason you can't revoke your old key it will die of old age. The only disadvantage of finite-lifetime keys is having to generate, distribute and get people to use your new keys periodically.

I used to use only non-aging keys but have become convinced that the pros of expiration dates outweigh the cons. Therefore, I recommend that you set your key to expire after no more than 18 or 24 months. For me, one year is too short (tempis fugit!), but I doubt that a key much older than a year and a half or two years can stand up to the inevitable advances in computing power and/or factoring technology (i.e., public-key cracking methods) that will have occurred over its lifetime.

Next you need to specify a name, e-mail address and also an optional comment. Note that you can associate additional e-mail addresses with your key later by using gpg's --edit-key flag and issuing an adduid and/or an addkey command.

The last thing you need to think about in generating your key is a good passphrase. And I do mean passphrase: it can and should contain spaces. The longer it is, the more secure it is. You should also incorporate some combination of numbers, mixed case (e.g., bOTTLE rockeT) and punctuation. Lately, I've taken to generating my passphrases with dice and a word list. See diceware.com for a handy procedure for doing this yourself.

Whatever you do, don't choose a short, predictable or otherwise guessable passphrase. It doesn't have to look like “B1&SSja-sd0c as-d$%@KFSAAs-,ssd w0a-00sdp23m”, nor should it look like “My lame passphrase”. It's okay to write your passphrase on a small card you keep in your wallet if doing so makes it easier for you to use hard-to-guess passphrases. (Just be careful never to leave it sitting around and to always put it away when you're done with it!)