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

Your friend Dan Sparty has just e-mailed you a copy of his new public key, in the form of a file called danskey.asc. Here's how you import it to your public keyring:

gpg --import ./danskey.asc

But wait a minute. Internet e-mail isn't a very secure medium. How do you know Dan's key wasn't tampered with in transit, or that it even was Dan that sent it in the first place?

By checking its fingerprint, that's how. Every gpg key has a secure hash called a fingerprint that is unique to each key (pair) but is short enough to be read over the phone, written on a postcard, etc. If you call Dan on the phone and ask him to read you the fingerprint of his new key, it should match the output from the following command (executed on your system after importing his key):

gpg --fingerprint dan

Note that as with the --export command, you can specify just part of the key as long as that part is unique to the key you wish to fingerprint. The output will look something like this:

pub  1024D/C9F34866 2001-07-27 Dan Sparty (Party Down!)
       <dan@boogiemeister.org>
     Key fingerprint = D084 F92C EC62 8955 98E2  58FB
       178A 2673 D1F3 6866
sub  1024g/C5569A5B 2001-07-27 [expires: 2001-08-10]

Alternatively (let's say it's only noon and you don't want to wake Dan up), if Hugh has this fingerprint in his e-mail signature and has furthermore made postings to Usenet or on public e-mail lists, you can simply find one of these messages and compare that signature. This illustrates an important aspect of key fingerprints: the more places your public key and/or its fingerprint is archived, the harder it is for someone to pretend to be you.

Now that you know this is really Dan's new key and not a forgery, you can do Dan and the world a favor by publicly and cryptographically vouching for its veracity. In other words, you can sign it with your private key. To do so, you run gpg with the command --edit-key. This, like --gen-key, triggers an interactive session. Listing 3 shows a key-editing session in which the user signs a key with their own default key.

Listing 3. Editing (Signing) a Key

Did you notice the final save command? This saves any changes you've made to the key (in this case, the signature you created for it) and exits the key-editing session. If we now list the key with the command gpg --list-sigs dan we'll see:

jojo@linux:~ > gpg --list-sigs dan
pub  1024D/B9E0868B 2001-07-27 Dan Sparty (Party On!)
     <dan@boogiemeister.org>
sig        B9E0868B 2001-07-27  Dan Sparty (Party On!)
           <dan@boogiemeister.org>
sig        C1C34866 2001-07-27  John J. Figplucker
           (Smooth JoJo) <jojo@figpluckers-supreme.to>
sub  1024g/A0B78448 2001-07-27 [expires: 2001-08-26]
sig        B9E0868B 2001-07-27  Dan Sparty (Party On!)
           <dan@boogiemeister.org>

In addition to Dan's own signatures (when you generate a key it's automatically self-signed) you can now see JoJo's. Now, all that remains is for JoJo to export his new signed version of Dan's public key:

gpg --output dan_jojosig.asc --export dan

JoJo then needs to send this file to Dan via e-mail or some other convenient means (remember, it's a public key, so confidentiality isn't an issue), and Dan needs to import the signed key back into his own public keyring:

gpg --import ./dan_jojosig.asc

Importing may seem counterintuitive: Dan's actually updating his public key, not importing a new one. But trust me, that's what he needs to do in order to join the proud ranks of gpg users who actually have bothered to get their friends to vouch for their keys.

Now that Dan's got a superelite signed key, he's ready to post it to a keyserver so other people can start sending him encrypted messages (and adding their signatures to his key). To do so he can issue the command:

gpg --keyserver pgp.mit.edu --send-keys dan@boogiemeister.org

The option --keyserver is used to specify the name or IP address of a PGP/GPG keyserver. Alternatively you could add to ~/.gnupg/options a line like this:

keyserver pgp.mit.edu

But, note that doing so will cause gpg to download new keys automatically from the keyserver if it encounters an unknown key when verifying signatures.

Remember last month when I verified a detached signature file for a software package? The first time I tried to verify the signature with the gpgv command, I received an error message since the key used to create the signature wasn't present in my public keyring.

The solution was to query for, and download, the key from the keyserver pgp.mit.edu; this would have happened automatically if a keyserver had been set in my options file. It's up to you to decide whether this is a feature or an annoyance, and whether therefore to make it the default behavior. (The command-line option --no-auto-key-retrieve will override auto-key-retrieval.)