OpenPGP DSA-1 key rollover How to roll over/transition your 1024 bit DSA keys which are no longer secure to something better using either Thunderbird with Enigmail or GnuPG (GPG) command line interface
Show
Versions
Last Change
Print
Table of Contents:
1 About this document
1.1 Introduction
1.2 Translations
2 Why?
3 Who?
4 What’s required?
5 How to do it?
5.1 Update your GPG preferences
5.2 Create new key
5.3 Sign your new key using your old key
5.4 Publish your new key
5.5 Write and publish transition statement
5.6 Revoke old key
5.7 Outreach!
6 Extra hint: Refresh your copy of peoples’ keys regularly
6.1 Using (ana)cron on Linux
6.2 Using scheduled tasks on Windows
7 Related resources
About this document¶ Introduction¶
This document was first published at https://we.riseup.net/alster/openpgp-dsa1-key-rollover – updated versions will go there, too. Please ensure that you have the latest copy of this document by checking the version list.
This document is basically a rewrite of Daniel Kahn Gillmor’s excellent May 2009 article “HOWTO prepare for migration off of SHA-1 in OpenPGP” at debian-administration.org – but much simplified and rephrased for a less technical audience which just “wants it to work”. Note that there is no such thing as “just works” in security, since understanding how things work (and how not, and where its limits are exactly) is an essential component of security. However, people are often scared off by too technical documentation, so this one will be kept simple, and you still have the option of (and are encouraged to) reading up on everything on dkg’s weblog and elsewhere.
Normally, as Daniel describes in his weblog, you should prepare and roll over your keys along a period of a few months. However, if you are reading this document, which was only first published more than a year after it was about time to start rolling over your keys, then you are already late, and you will likely want to roll over your keys as soon as possible. As such, the preparatory process is omitted in this document.
I have tried to describe the process as simple as possible while trying to be roughly factually correct and not completely imprecise. I am, like any human, prone to error and may thus have gotten something wrong which could be equally well explained with correct facts. If you find this is the case, please contact me by email at alster at tachanka D0T org. If you would like to encrypt your email, please use the 0x778E467839A8722D key as found in the SKS keyserver pool (http://sks-keyservers.net).
You are welcome to share and remix this document under the terms of the CreativeCommons Attribution-NonCommercial-ShareAlike 3.0 Unported license. Translations¶
Portuguese – thanks Drebs!
Why?¶
This section is going to be a little technical, so if you’re already convinced you need to roll your key(s) over then just skip this.
Encryption usually relies on so-called hash functions, a method to create, for a given text, an almost unique alternative representation, a so-called digest. This method should, however, only work in one direction, so you can create the digest from the text but can not recover the original text from the digest, even though each digest just stands for very few original texts. If you were able to do this, this hash function would be considered broken and could be no longer used for encryption.
GPG also makes use of such hash functions during message signing. Traditionally GPG would create so-called DSA keys, which were limited to 1024 bit key length and to using 160-bit sized hashes, traditionally using the SHA-1 hash function. Most people will have generated such keys during the past decade. The issue with these keys is two-fold: with new developments in cryptanalysis (“hacking encryption”) in recent years, 1024 bit keys need to be considered short now. What’s worse, the SHA-1 hash function has immanent design issues which show that you can create the same hash using two different original texts considerably easier than you should be able to. That’s a bad omen and a good reason to replace one hash function by another.
So you need both longer (>= 2048 bit) keys and an encryption mechanism which works with a hash function which is not weak. DSA fails on both fronts. The other common encryption scheme named RSA has been supported by most encryption software since a long time and perfectly meets the requirements, too. Therefore, this document will discuss how to create new RSA keys. Who?¶
Everyone who is currently using DSA keys with 1024 bit length, which have been the default key type in GPG for quite a while, should roll over (i.e. replace) their keys. Actually everyone using DSA OR RSA primary keys shorter than 2048 bit should do it.
To determine which keys you have open a terminal window and enter:
gpg --list-secret-keys
All lines starting ‘sec 1024D’ indicate keys which need to be replaced (unless you already did, but you will be aware of it if you already did it).
This command lists the key IDs of those of your keys you need to replace, including expired or revoked keys:
gpg --list-secret-keys --with-colons | awk -F : '{ if ( $1=="sec" && $3=="1024" && $4=="17" ) print $5 }'
To inspect these in detail, use:
gpg --fingerprint --list-keys gpg --list-secret-keys --with-colons | awk -F : '{ if ( $1=="sec" && $3=="1024" && $4=="17" ) print $5 }'
If it does not work for you, just look up the keys to be replaced as explained in the first command above. Take a note of the ‘sec’ key IDs (the 8 or 16 character code), you will need them later. What’s required?¶
This document is mostly targeted at Linux users. The commands provided were tested on Ubuntu 10.04 (Lucid Lynx), but may apply to other operating systems just as well. Being somewhat comfortable with typing commands into a terminal window / working with a command line is a requirement, too.
This document requires you to use a GPG 1.x version higher than or equal to 1.4.10 (It may also work with GPG 1.4.9, but you may need to create your RSA key pair in two separate steps using the GPG command line interface then), or a GPG 2.x version higher than or equal to 2.0.16. To determine your GPG version, use:
gpg --version
It is also required that you use Thunderbird 3.0 or higher and Enigmail 1.0.1 or higher (but Thunderbird 2.0 and Enigmail 0.96.0 are assumed to work, too). You should be able to determine which versions you have installed using the Thunderbird menu options “Help” → “About Thunderbird” and “OpenPGP” → “About OpenPGP” respectively.
If any of your versions are too low, please consult the documentation your operating system provides for installing updated versions. How to do it?¶ Update your GPG preferences¶
Run a text editor such as Vim, Nano, Jed, Pico, GEdit, Kate, Wordpad, Notepad++ (but not Notepad!). Open the GPG configuration file which is located in your home directory in a hidden subdirectory called .gnupg, in a file called gpg.conf. For example:
nano /home/alster/.gnupg/gpg.conf
Go to the end of this file, add a blank new line, then paste this:
personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Save the file and exit the text editor. Create new key¶
Back to the list of keys you are going to phase out (see above on how to determine which keys to replace). For each of these keys you want to replace (i.e. those you still need), you should now create new ones, using the RSA encryption scheme and at least 2048 bit length. This can be done with either Enigmail or GPG directly (using the command line interface).
Using Enigmail:
Restart Thunderbird.
In Thunderbird, in the “OpenPGP” menu, select “Key Management”. A new window, “OpenPGP Key Management”, will open.
In the “Generate” menu, select “New Key Pair”. A new window, “Generate OpenPGP Key”, will open.
Select the (Thunderbird) “Account / User ID” to create the key for. This will be the identities (email addresses/accounts) whose legacy keys you are replacing.
Tick “Use generated key for the selected identity”.
Untick “No passphrase”. Enter a passphrase for the new key you are about to create. Please read up on the Internet on how to create a secure passphrase. At the time of writing, a sufficiently secure password for a GPG key should consist of multiple upper and lower case characters as well as some digits and special characters, and be no shorter than 16 characters. Please also consider using both a password generator and manager software. Using a password manager is more or less the only way to have secure passwords or passphrases nowadays.
Enter a “Comment” only if you need to, and keep it short if so
Set “key expiry” to no more than 2 years. Make sure that you will be reminded a few days in advance of this date of expiry so that you can expand your keys’ lifetime then. The idea behind this expiry time is that it can serve as a last resort if you need to declare your key invalid, but lost access to both your secret key (so that you cannot generate a revocation certificate) as well as your revocation certificate. Another reason why an expiry helps is that when you actively expand your keys’ lifetime later (ideally before it expires), you provide other people with an indication that you are still able to manage this key, and you get to know when other people fail to regularly update their keys from a key server (where you would need to publish your key whose lifetime you extended).
Click the “Advanced” tab and select a “key size” of at least “2048”. Longer keys are more cryptographically secure and their encryption will likely be unbreakable for longer, so 4096 bits is a good choice if your CPU is not already too busy in general (an issue many netbooks, smartphones and tablets have). Set “key type” to “RSA”. If this option is not available then you are running an outdated version of either Enigmail or GPG. See above for requirements.
Click on “Generate key”, verify that it is about to do the right thing, and confirm.
Wait. Download some files from the Internet, or browse some web pages, or unpack some files on your hard disk to speed it up.
Generate a revocation certificate when asked for it. Save it to a place where it both cannot easily get lost (such as due to a broken hard disk) and nobody else can access it, and do this now, really. Once the revocation certificate has been stored, the window closes and you are back to the “OpenPGP Key Management” window. Search for the identity (email address) you have created the new key for and inspect your newly created key – double-click it for detailed “Key Properties”.
Note down the fingerprint of this newly created key, you will need it later
Optionally, to add additional identities (email addresses) to this key: in the “Key Properties” window, click on “Select action”, then “Manage User IDs”. Then click on “Add”, enter your display name and email address, confirm. Finally select the key you want to be your primary ID, and click on “Set primary”, then “close window”.
Using GPG on the command line:
Run:
gpg --gen-key
Choose “RSA and RSA” key type. If this option is not available then you are running an outdated version of GPG. See above for requirements.
Select a key size of at least “2048” bit. For compatibility reasons, it’s best to pick one of “2048” or “4096” bit. Longer keys are more cryptographically secure and their encryption will likely be unbreakable for longer, so 4096 bits is a good choice if your CPU is not already too busy in general (an issue many netbooks, smartphones and tablets have).
Set key expiry to no more than “2y” (two years) and confirm if it is correct. Make sure that you will be reminded a few days in advance of this date of expiry so that you can expand you keys’ lifetime then. The idea behind this expiry time is that it can serve as a last resort if you need to declare your key invalid, but lost access to both your secret key (so that you cannot generate a revocation certificate) as well as your revocation certificate. Another reason why an expiry helps is that when you actively expand your keys’ lifetime later (ideally before it expires), you provide other people with an indication that you are still able to manage this key, and you get to know when other people fail to regularly update their keys from a key server (where you would need to publish your key whose lifetime you extended).
Enter the “real name” which is a text everyone will be able to see.
Enter the “email address” associated with the new key you are creating.
Optionally enter a “comment”, but if you need to, keep it short.
Correct as needed, then hit ‘O’.
Enter the new keys’ passphrase twice. At the time of writing, a sufficiently secure password for a GPG key should consist of multiple upper and lower case characters as well as some digits and special characters, and be no shorter than 16 characters. Please also consider using both a password generator and manager software. Using a password manager is more or less the only way to have secure passwords or passphrases nowadays.
Wait. Download some files from the Internet, or browse some web pages, or unpack some files on your hard disk to speed it up.
Copy/note down the key ID and fingerprint of your newly created key.
Generate a revocation certificate for your new key (replace ‘’ by your new keys’ ID you just noted down):
gpg --output "<Key ID>_rev.asc" --gen-revoke <Key ID>
Confirm you want to create a revocation certificate, then choose reason “1 = key has been compromised”
For “optional description”, just press Enter.
Confirm and enter your new keys’ passphrase.
Your revocation certificate has been written to a file “_rev.asc”. Follow the instructions on screen and save it to a place where it both cannot easily get lost (such as due to a broken hard disk) and nobody else can access it, and do this now, really.
Optionally, to add additional identities (email addresses) to this key, run:
gpg --edit-key <Key ID> adduid
Then follow the instructions on screen.
Sign your new key using your old key¶
You should let other people know that you (who was using your old key so far when communicating with them) fully trust that other key (the one you just created). If you would not do this, your new key would look just like any other key to them. Sure, it does have your email address on it and this new keys’ user (you) would claim that this is ‘my new key, replacing the old one’. But for the other people this would just be someone claiming this, who could just as well be imposing you. However, if you sign your new key with your old key and make this signature visible/available to others this is at least some indication that this new key can actually be somewhat trusted. It does not yet explain that this is the replacement key for the old one, but we will get to this later.
Using Enigmail:
If you closed it, reopen the “OpenPGP Key Management” window (“OpenPGP” → “Key Management”)
Find your newly created key by searching for (in the Search for: field) it’s 8 character key ID – the one you noted down earlier.
Right-click your newly created key and select “Sign key” – a new window ‘OpenPGP – Sign key’ will open.
Verify this is really, really, really your new key by comparing the given fingerprint to the one you noted down earlier.
For ‘key for signing’, select your old DSA key. Make sure you don’t accidentally select your new key for signing your new key there, in which case the text “Note: the key 0×........ is already signed with the selected secret key” will display and the ‘OK’ button will be disabled.
For the question on how much you trust this key you are about to sign, you can select “I have done very careful checking”, since this is going to be your new key which you trust ultimately, and you just verified it’s really, really, really, the right key by comparing the fingerprints.
Do not tick “Local signature”, even if you usually do this for privacy reasons, since this signature is really one you want to have others see, too.
Click OK and enter your old keys’ passphrase.
Once the signature is done, you are back to the ‘OpenPGP Key Management’ window. If you would like to verify that your signature has been made, you can right-click the new key and select ‘View Signatures’ – the signature you just made should be listed there.
Using GPG:
Run:
gpg -u <Legacy key ID> --edit-key <New key ID> tsign
Verify that you are really, really, really about to sign your new key with your old key by comparing the key IDs and fingerprints to those you noted down earlier.
For the questions on how much you trust this key you are about to sign, you can select the full trust options, since this is going to be your new key which you trust ultimately, and you just verified it’s really, really, really, the right key by comparing the fingerprints.
Confirm and enter your old keys’ passphrase when asked for it.
Publish your new key¶
To allow other people easy access to your new key as part of the transition and whenever they need it later, you should publish it on a keyserver.
Using Enigmail:
If you closed it, reopen the “OpenPGP Key Management” window (“OpenPGP” → “Key Management”)
Search for the newly created key. Ensure it is really the right one, the one you just created.
Right-click on the newly created key and select “Upload Public Keys to Keyserver”. Choose your preferred keyserver to publish to. If you don’t know one, I suggest you send it to “x-hkp://pool.sks-keyservers.net” or pick one of those listed in the ‘Servers in the pool’ section on sks-keyservers.net/status . Note that you can configure your preferred keyserver(s) in Enigmail preferences.
Using GPG:
Run:
gpg --send-key <Key ID>
Alternatively, to send to a specific keyserver, use:
gpg --keyserver <Keyserver URL> --send-key <Key ID>
Write and publish transition statement¶
Now you need to let everyone know that you’re rolling your keys over. And in a way they can actually know it is you telling them this, and that you are actually in possession of this new key you created. Open up a text editor and write up a transition statement (here’s an example from Daniels’ earlier key transition – be sure to replace his GPG key IDs by your own old and new key IDs), then save it to a file, say, “openpgp-transition-2010.txt”.
Now sign this file with both your old and new keys:
gpg -u
You will be asked for the two keys’ passphrases, then GPG will create a file openpgp-transition-2010.txt.asc which is your signed transition document. You no longer need the original document “openpgp-transition-2010.txt” now and can delete it. You should now make this document generally available by placing it on a public website. Since not everyone has access to a web server, a good enough option is to publish the document (just copy and paste from “openpgp-transition-2010.txt.asc”) on pastebin.com or a similar service (optionally using an anonymization service such as Tor). If you decide to use pastebin.com, once you have submitted it, click on the ‘RAW’ link on the top right of your transition statement. You should then end up with a page showing nothing but the raw transition statement exactly as it looks in the file you just created. Copy the URL of this web page from your web browsers’ location bar, it should look something like http://pastebin.com/raw.php?i=gwA3EfPj. You will need this Internet address later. Revoke old key¶
You should now revoke every of your old DSA keys. Revoking them ensures that other people having a copy of your public key will no longer be able to encrypt to it, and will realize that email signed by this key is no longer trusted. You will, however, still be able to read all email others have sent to you (and encrypted to your old key) during the past years.
Using Enigmail:
If you closed it, reopen the “OpenPGP Key Management” window (“OpenPGP” → “Key Management”)
Search for you legacy key. Ensure it is really the right one, the DSA one you no longer wish to use.
Right-click on this key and select “Revoke”, verify that it is about to do the right thing, and confirm, then enter your passphrase.
Finally, publish your revoked key to a key server, just as you did for your new key above.
Using GPG:
First generate a revocation certificate for your old key (replace ‘’ by your old keys’ ID as noted down earlier):
gpg --output "<Key ID>_rev.asc" --gen-revoke <Key ID>
Confirm you want to create a revocation certificate, then choose reason “2 = Key is superseded”
For “optional description”, you may enter something like this (replacing by your newly created keys’ ID):
This key has been replaced by
Confirm and enter your new keys’ passphrase.
Your revocation certificate has been written to a file “_rev.asc”.
Now import this revocation certificate:
gpg --import "<Key ID>_rev.asc"
Your key is now revoked.
Finally, publish your revoked key to a key server, just as you did for your new key above.
Outreach!¶
Send email to your friends whom you have been encrypting with in the past, and who have signed your key in the past, pointing them to your published transition statement (you can also attach the transition statement file if you prefer).
Change your email text signature (the stuff that Thunderbird may be adding to the end of every email you compose) so that it points to your transition statement, and include a notice that your a rolling your keys over.
Write up or print out the user IDs and fingerprints of your new key on paper to hand out to people you want to sign your new key.
Organize or take part in meetings with your peer group(s) and mutually sign your GPG keys, then publish your updated keys to a keyserver.
Extra hint: Refresh your copy of peoples’ keys regularly¶
You should regularly update your local copy of keys from a key server. How to do this depends on your operating system. Using (ana)cron on Linux¶
On Linux you would probably want to create a per user (i.e. not system-wide) cron job. To do so, you edit your users’ crontab:
crontab -e
An editor will spawn, now add this to the end of this file:
@daily /usr/bin/gpg --refresh-keys > /dev/null 2>&1
This will ensure that your GPG keys get updated from your default keyserver (as configured in ~/.gnupg/gpg.conf – I recommend using pool.sks-keyservers.net or a keyserver which supports the transport encrypted HKPS protocol) once a day.
If you prefer it to happen by a fixed time you could use this instead (or additionally):
0 1 * * * /usr/bin/gpg --refresh-keys > /dev/null 2>&1
This would run it every night at 01:00 AM. Note, however, that the latter cron job will not be executed if your computer is not running by this exact time. If you would like to run it at a different time, run man 5 crontab to read the manual for the crontab command which also explains the format of this file. Note also that the special ‘@daily’ format may not work on all Unix derivates (it depends on anacron).
You can optionally add a second line to ensure you start with up to date GPG keys whenever your computer boots up:
@reboot /usr/bin/gpg --refresh-keys > /dev/null 2>&1
Using scheduled tasks on Windows¶
On Windows, you would define ‘scheduled tasks’ to achieve the same thing. How to do this exactly is out of the scope of this document. You should be able to find several documentations on the Internet, though. Related resources¶
The GNU Privacy Guard (GPG) website
The GNU Privacy Guard (GPG) on Wikipedia
OpenPGP Alliance website
OpenPGP Best Practices an excellent resource by RiseupLabs
How to OpenPGP by the Apache Software Foundation
Creating a new GPG key blog entry explaining the key transition