notes on my experience creating a new strong gpg key and getting caff to use it
authorBdale Garbee <bdale@gag.com>
Tue, 28 Jul 2009 14:49:12 +0000 (16:49 +0200)
committerBdale Garbee <bdale@gag.com>
Tue, 28 Jul 2009 14:49:12 +0000 (16:49 +0200)
bdale/blog/posts/Strong_Keys.mdwn [new file with mode: 0644]

diff --git a/bdale/blog/posts/Strong_Keys.mdwn b/bdale/blog/posts/Strong_Keys.mdwn
new file mode 100644 (file)
index 0000000..a25838b
--- /dev/null
@@ -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!
+