OpenPGP Key Transition

I’m a terrible person: I kept my 2007-vintage 1024D OpenPGP keypair around for the longest time, even though I should have discarded it several years ago.

To give you an idea about the depths of slothfulness and procrastination I have fallen into: all Debian developers phased out their 1024-bit DSA keys around 2009 or so. I found it fit to transition to a new key a good six years later. Shame on me!

In my defense, I rarely ever send or receive encrypted email. (Not entirely true: I received a deluge of encrypted, signed, and encrypted and signed email – both OpenPGP and S/MIME – from my students, when I was TA-ing a security class, but back then I was a stressed out graduate student, and I indeed didn’t see the occasion fit to upgrade my GPG/PGP keypair.)

In my further defense, using PGP is not the most intuitive task one might perform with a computer: as some people argue, it might be even time for PGP to die. It still is one of our best defenses against several hostile actors today, so until something better comes along, using PGP is a good idea.

Ideally the lack of email encryption should change: not only to protect privacy, confidentiality, and integrity of our email messages, but also as a means of protest against mass surveillance, both by various private entities and by governments; and to support principled free software developers like Werner Konch, who keep pressing on.

Anyway, my story is that I’m transitioning to a RSA 4096-bit PGP key. Tradition mandates that one must publish a transition statement on an occasion like this. My transition statement is available here, and it is signed with both my old and new keys to validate the transition:

(The statement was updated to use long 16-character key IDs.)

You can download the statement and gpg --verify it against the old and new keys, given below. I have also posted the new public key, as well as the old one, for good measure.

The old key (id 0xB4D228AD9DB8FF06) is now set to expire in an year:

pub   1024D/0xB4D228AD9DB8FF06 2007-09-02 [expires: 2016-04-21]
      Key fingerprint = CB80 0BA6 7D13 B10A 6FBB  D43E B4D2 28AD 9DB8 FF06

And the new key is:

pub   4096R/0x0C6DA6A29D5F02BA 2015-04-22 [expires: 2020-04-20]
      Key fingerprint = 22D9 BFBA 256B 7BFA 7B16  187C 0C6D A6A2 9D5F 02BA

The new key, signed with the old key, should be present in and should eventually propagate to other keyservers as well. If you have signed my old key in the past, please consider signing my new key as well, after the necessary verification steps. (Thank you!)


Because I will forget what I have done any moment from now, I thought it would be a good idea to write down what I have done:

1. Update ~/.gnupg/gpg.conf

Added these lines to the bottom of ~/.gnupg/gpg.conf:

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

keyid-format 0xlong

2. Create new key

gpg --gen-key

Be sure to pick a 4096-bit RSA key. Some folks have been using 8192-bit keys as back as 2009 by patching GPG sources. Somewhat surprisingly 8192-bit keys aren’t available in GPG official releases even today! Since I have no inclination to mess with sources, I chose a 4096-bit RSA key.

3. Add other UIDs

Here’s where you add your all other email addresses.

gpg --edit-key [new key id]
command> adduid
command> save

4. Set primary UID

We need to designate one of the UIDs as the primary one.

gpg --edit-key [new key id]
command> uid 1
command> primary
command> save

5. Generate a revocation certificate

This is for future use. The revocation certificate must be stored away somewhere safe.

gpg --gen-revoke [new key id] > [new key id]-revoke.asc

6. Sign new key with old key

Assure the world that both belong to the same person.

gpg --default-key [old key id] --sign-key [new key id]

7. Publish the new key

Send the new key to a friendly neighborhood public key server.

gpg --keyserver --send-key 9D5F02BA

8. Write a transition statement

Write the traditional transition statement, and sign it with the old and new keys:

gpg -a -u [old key id] -u [new key id] --clearsign statement.txt

9. Holler from the rooftops

In addition to the public keys, publish the transition statement, write a blog post, tweet about it, and publish the new key in, like all the cool kids do these days.

10. Profit?

Hardly. This ain’t no such business.


(Posted on April 22, 2015.)