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.)
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 keys.gnupg.net 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 with-fingerprint
2. Create new 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 keys.gnupg.net --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 keybase.io, like all the cool kids do these days.
Hardly. This ain't no such business.