unfolding disasters/ posts/ GnuPG maintenance

It's a good idea to periodically replace old PGP encryption keys to minimize the amount of data exposed by cracking the old key.

$ gpg --expert --edit-key F15F5BE8
…
pub  1024D/F15F5BE8  created: 2008-08-09  expires: 2011-08-08  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048g/42407C74  created: 2008-08-09  expired: 2009-08-09  usage: E   
sub  2048g/4DA3FC0B  created: 2009-07-26  expired: 2010-08-08  usage: E   
sub  1024D/EB357E60  created: 2009-07-26  expired: 2010-08-08  usage: S   
[ultimate] (1). William Trevor King <wking@drexel.edu>
[ultimate] (2)  William Trevor King <tvrkng@gmail.com>

The usage characters are:

  • e = encrypt/decrypt
  • s = sign
  • c = certify (sign another key)
  • a = authenticate (e.g. log in to SSH with a PGP key)

See doc/DETAILS in the GnuPG source directory for details on the output format (and the related colon listing format).

If your primary key has expired, you can extend its expiration time with

gpg> expire

Note that my encryption keys have expired. This makes it hard for people to send me encrypted mail. Create a new encryption key with

gpg> addkey

Answering the prompts as you see fit (I usually pick Elgamal for encryption). You can also add signing keys with addkey (I usually pick RSA for signing, since DSA keys are limited to 1024 bits, see ssh-keygen(1)).

There doesn't seem to be much to differentiate Elgamml vs. RSA for encryption. With the --expert mode, you can select

RSA (set your own capabilities)

so that's what I do (since then I only need one subkey for all tasks).

Several gpg operations require a particular subkey to be selected. Use key to select subkeys by index (marked with a *):

gpg> key 1

pub  1024D/F15F5BE8  created: 2008-08-09  expires: 2012-05-24  usage: SC  
                     trust: ultimate      validity: ultimate
sub* 2048g/42407C74  created: 2008-08-09  expired: 2009-08-09  usage: E   
sub  2048g/4DA3FC0B  created: 2009-07-26  expired: 2010-08-08  usage: E   
sub  1024D/EB357E60  created: 2009-07-26  expired: 2010-08-08  usage: S   
sub  2048g/3FB721E8  created: 2011-05-25  expires: 2012-05-24  usage: E   
sub  2048R/9CADC4D9  created: 2011-05-25  expires: 2012-05-24  usage: S   
[ultimate] (1). William Trevor King <wking@drexel.edu>
[ultimate] (2)  William Trevor King <tvrkng@gmail.com>

If you get confused, there's also a help command.

Save and quit when you're done:

gpg> save

Once you've got your key all fixed up, upload the new version to your chosen keyserver:

$ gpg --send-keys F15F5BE8

You probably also want to post your new key somewhere on your website:

$ gpg --export --armor -o ~/.gnupg/pubkey.txt F15F5BE8
$ scp ~/.gnupg/pubkey.txt you@somewhere:public_html/pubkey.txt

Checking signatures

Here are some quick notes on checking signatures:

$ gpg --check-sigs F15F5BE8

will list the status of signatures for which you have the signing key in your keyring. However, if you are missing one of the signing keys, you may get a message like

10 signatures not checked due to missing keys

If you run

$ gpg --list-sigs F15F5BE8

you'll see all the signatures, and you can use the usual gpg --recv-key KEYID to check out the ones you don't have.

Adding user IDs

If you get a new email account, you'll want to add it to your key. 

$ gpg --edit-key F15F5BE8
gpg> adduid
…

Optionally make the new ID your primary ID.

gpg> uid 3
gpg> primary

Finall, save your changes.

gpg> save

Don't worry about the [unknown] trust level next to your new ID. Once you've saved the key, it will change to [ultimate]. I imagine the initial [unknown] listing is because you haven't officially confirmed the new ID's signature by saving your changes.