From b96b2172effe99a3c2273b3198742bd8dd13ac9f Mon Sep 17 00:00:00 2001 From: Bdale Garbee Date: Tue, 28 Jul 2009 16:49:12 +0200 Subject: [PATCH] notes on my experience creating a new strong gpg key and getting caff to use it --- bdale/blog/posts/Strong_Keys.mdwn | 69 +++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 bdale/blog/posts/Strong_Keys.mdwn diff --git a/bdale/blog/posts/Strong_Keys.mdwn b/bdale/blog/posts/Strong_Keys.mdwn new file mode 100644 index 0000000..a25838b --- /dev/null +++ b/bdale/blog/posts/Strong_Keys.mdwn @@ -0,0 +1,69 @@ +[[!tag tags/debian]] +[[!tag tags/crypto]] +In recent months, a number of arguments have been made in favor of abandoning +use of [SHA-1](http://en.wikipedia.org/wiki/SHA_hash_functions), 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"](http://pgp.cs.uu.nl/doc/top_50.html). 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](http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/) +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](http://fortytwo.ch/gpg/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](http://pgp-tools.alioth.debian.org/) repository that ends up as the [signing-party](http://packages.debian.org/signing-party) package in Debian to do all my key signing. Unfortunately it has a +[bug or feature](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527944) +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 use 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! + -- 2.30.2