Jul 20 2012

Print this Post

gpg key upgrade

Following a recent discussion about gpg key signing on my local linux user group email list, one of the members pointed out that several of us (myself included) were using rather old 1024-bit DSA GPG keys with SHA-1 hashes. He recommended that such users should upgrade to keys with a minimum size of 2048 bits and a hash from the SHA-2 family (say SHA256).

I believe he is right. That is good advice and it is long past time that I upgraded. So, I have now created a new default GPG key of 4096 bits – that should last for a while. However, that leaves the problem of how to migrate from the old key to the new key when the old key has been in circulation since at least 2004.

Fortunately, Daniel Kahn Gillmor (dkg) has published a rather nice and useful how-to on his debian-administration blog. I used that guide, supplemented with some further guidance on the apache site to come up with a transition plan. If you wish to contact me securely in future, then please use my new GPG key. My signed transition statement is here. A copy is given below. That transition statement is signed with both my old and new keys so that people who have my old key may be sure (or as sure as they can be if they presume that my old key has not been compromised) that the new key is valid and a true means of secure communication with me.

(BTW, the way to sign a document with two keys is as follows:

gpg –clearsign –local-user $KEYID-1 –local-user $KEYID-2 filename

where $KEYID-1 and $KEYID-2 are the eight digit IDs of the old and new keys. This is not well documented in the GPG manual.)

Copy of transition statement

Hash: SHA1,SHA256

GPG transition statement – Friday 20 July 2012

I am moving my preferred GPG key from an old 1024-bit DSA key to a
new 4096-bit RSA key.

The old key will continue to be valid for some time, but I prefer all
new secure correspondence to be encrypted with the new key. I will be
making all new signatures with the new key from today.

This transition was aided by the excellent on-line how-to at:


This message is signed by both keys to certify the transition.

The old key was:

pub 1024D/10927423 2004-07-15

Key fingerprint = E8D2 8882 F7AE DEB7 B2AA 9407 B9EA 82CC 1092 7423

And the new key is:

pub 4096R/5BADD312 2012-07-20

Key fingerprint = FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312

I have signed my new key with the old key. You may get a copy of my
new key from my server at rlogin.net/keys/micks-new-public-key.asc

To fetch the new key, you can get it with:

wget -q -O- http://rlogin.net/keys/micks-new-public-key.asc

Or, to fetch my new key from a public key server, you can simply do:

gpg –keyserver keys.gnupg.net –recv-key 5BADD312

If you already have my old key, you can now verify that the new key is
signed by the old one:

gpg –check-sigs 5BADD312

If you don’t already know my old key, or you just want to be double
extra paranoid, you can check the fingerprint against the one above:

gpg –fingerprint 5BADD312

Please let me know if you have any trouble with this transition. If you
are also still using old 1024-bit DSA keys, you too may wish to consider
migrating your old key to a stronger version.


Version: GnuPG v1.4.11 (GNU/Linux)


Permanent link to this article: http://baldric.net/2012/07/20/gpg-key-upgrade/


  1. David

    How does one ensure that they are not coerced into signing a transition statement with a new (but compromised) key?

    I really should check my own GPG key, it might be >1024 bits out of paranoia..

  2. Mick


    A similar objection was raised in the ALUG discussion. In response I’d amplify the argument used by Richard in response to Jonathan: viz. if you are not trusting the new key on the simple grounds that the transition statement can’t be trusted, then you must assume that the old key is also compromised and can’t be trusted. But you were content to use that key until the transition statement appeared. What has changed?


Comments have been disabled.