In recent months, a number of arguments have been made in favor of abandoning use of SHA-1, which I won't rehash here (yes, pun intended!). The practical consequence that matters to me is that many Debian developers are in the process of transitioning to new, stronger gpg keys, and in the process also moving to generate more strongly coded key signatures.

While at Debconf9 this week, I succumbed to peer pressure, and have generated a new 4096-bit RSA key 0xC095D941 which I will henceforth use as my primary key. I note in passing that my previous key 0xF2CF01A8 is just over 10 years old, and thanks largely to my intense business travel in recent years and willingness to engage in key signings everywhere I go, had risen to be one of the world's best connected keys and thus very near the center of the "strong set". Since I have no evidence that this key has been compromised, I have no intention to immediately revoke it, and in fact will continue to sign keys with both my old and new keys for at least a while until my new key establishes itself. In the process of creating and setting up my new key, I stumbled over some issues that I think others should be aware of.

To create a strong key, there are several reasonable recipes, and following one is a good idea. I started with these notes from Ana's blog. Make sure to read the followup comments and follow the suggestion to add the algorithm preferences to the gpg.conf file before creating your new key, so that you don't have to update the preferences manually afterwards. I also learned a lot by reading about using multiple subkeys here... while the document says it's out of date, most of the important bits are still completely accurate. With these two documents, and a little man page review, creating my shiny new key was pretty easy.

For quite some time, I've been exclusively using caff (which stands for "CA - fire and forget") from the PGP Tools repository that ends up as the signing-party package in Debian to do all my key signing. Unfortunately it has a bug or feature relating to the use of a distinct home for gpg within the ~/.caff directory such that new options added to my normal ~/.gnupg/gpg.conf file were not noticed by caff! So even though I moved to a new strong key, I was continuing to generate weak SHA-1 signatures with the new key! The fix for this turned out to be simple enough (after burning a half-hour or so figuring out what the problem was!), I just created a symbolic link so that ~/.caff/gnupghome/gpg.conf points to my canonical gpg.conf file, and all was well. Or, almost all...

It bothered me that I had generated weak signatures with my new strong key, so I decided to re-sign the keys I had already signed with my new key so that all the signatures issued with my new strong key are strong signatures. To do this, I used gpg's --edit-key option with gpg warped to point to the caff home to 'delsig' the signatures I'd made to these keys, then used caff with the '--no-download' option to re-sign the keys and re-issue the associated emails. Trolling ~/.caff/keys helped me discover which keys were in the affected set, then I studied the command lines caff was feeding to gpg to see what options I'd need for gpg. Here's an example of the commands required to fix key id 0x2DA8B985:

gpg --homedir=/home/bdale/.caff/gnupghome --secret-keyring /home/bdale/.gnupg/secring.gpg --no-auto-check-trustdb --trust-model=always --edit-key 2DA8B985
caff --no-download 2DA8B985

I haven't fixed all the signatures made this week yet, but I will. Those of you who think I'm just re-sending the same signatures, take note of what's really going on! I understand that adding the new signatures works and you'll end up with my stronger signatures replacing the weak ones.

Hope this helps someone else avoid the frustration I felt while chasing these details down last night late!