GPG key migration and application compatibility testing

This page documents the results of the investigations performed for the GPG migration blueprint.

Migration Checklist

This list is based on the excellent instructions from Debian.

• Set defaults in ~/.gnupg/gpg.conf and ~/.caff/gnupghome/gpg.conf:

  personal-digest-preferences SHA512
  cert-digest-algo SHA512
  default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

• Generate a RSA/RSA key with 4096 bits. (gpg --gen-key)

• Edit the newly created key (gpg --edit-key NEWID):

• Validate that the preferences list the stronger ciphers first (showpref):

  •      Cipher: AES256, AES192, AES, CAST5, 3DES
         Digest: SHA512, SHA384, SHA256, SHA224, SHA1
         Compression: ZLIB, BZIP2, ZIP, Uncompressed
         Features: MDC, Keyserver no-modify

  • Add all the needed email addresses (adduid)

  • Set primary uid (uid and primary)

  • Save changes (save)

• Generate revocation cert and save somewhere safe (gpg --gen-revoke NEWID > NEWID-revoke.asc)

• Sign the new key with the old key (gpg --sign-key NEWID)

• Publish new key (gpg --keyserver pgp.mit.edu --send-key NEWID, gpg --keyserver keyserver.ubuntu.com --send-key NEWID)

• Write up transition statement (see here for examples)

• Sign transition statement with both keys (gpg -u OLDID -u NEWID --clearsign transition.txt)

• Publish transition (blog, twitter, etc)
• Collect signatures

• Add to Launchpad https://edge.launchpad.net/~LPUSER/+editpgpkeys

• Sign things that are still active with your new key and send to their owners.

  • You can validate signatures are using non-SHA1 by using gpg --list-packets < SIGFILE, and checking that digest algo is not "2" (SHA1). For SHA512, you'd want "10" (see RFC4880 sections 9.1 and 9.2 for details):

    :signature packet: algo 1, keyid xxxxxxxxxxxxxxxx
            version 4, created 1285621931, md5len 0, sigclass 0x10
            digest algo 10, begin of digest e3 3f

• Make new key your default (~/.caffrc, ~/.devscripts, ~/.muttrc, etc)

• When ready (e.g. 90 days), publish revocation cert for the old key.

Results of testing with SHA2 GPG keys

gmail/firegpg

• Investigated by sbeattie

GMail has no built in gpg support, though it's a requested feature.

The Firefox plugin FireGPG at one time supported GMail; however, it frequently broke and so the author decided to discontinue support for the plugin, due to frequent breakage by GMail. Experiments done in the past confirmed this breakage, though when FireGPG could identify a gpg-signed message, it did not seem to have any trouble verifying messages using SHA512 HMAC.

mutt

• Investigated by sbeattie

The MUA mutt makes direct use of gpg to perform its signatures, encryption, and verification, so as long as the version of gpg that mutt invokes supports SHA2, then it works within mutt. Experimentally, after I migrated my key, I continued to have no difficulty verifying, signing and encrypting emails with mutt, which is my default day-to-day email client.

KMail

• Investigated by jdstrand

KMail 4.4 (in Lucid and Maverick) is known to work with GnuPG2 and uses Kleopatra and the libkleo4 libraries to perform its signatures, encryption, and verification. KMail was specifically designed to work with GnuPG2¹. GnuPG2 2.0.13 uses SHA-256 by default and GnuPG2 in Lucid and Maverick (2.0.14) is confirmed to work with the strong defaults as recommended by Debian². I was able to sign, verify and encrypt mails using a RSA-2048 key, as well as verify a RSA-4096 signed USN from Steve Beattie.

1. http://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.html

2. http://www.debian-administration.org/users/dkg/weblog/48

PGP8 compatibility

• Investigated by jdstrand

PGP 8 compatibility is likely desirable for interacting with users of PGP8 or !GnuPG users who use the --pgp8 flag. From the gpg man page:

       --pgp8 Set up all options to be as PGP 8 compliant as possible. PGP 8
              is a lot closer to the OpenPGP standard than previous versions
              of PGP, so all this does is disable --throw-keyids and set
              --escape-from-lines. All algorithms are allowed except for the
              SHA224, SHA384, and SHA512 digests.

Therefore using the recommended options¹ should be fine since SHA256 is listed as one of our allowed digests:

Command> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

1. http://www.debian-administration.org/users/dkg/weblog/48

Evolution

• Investigated by mdeslaur

Maverick

Lucid

Bugs

1. Signing a new message will use SHA1, with no possibility of changing the default algorithm. This has been fixed in the upstream 2.31 branch, but there are no plans to backport to 2.30, as it will change API.

   • https://bugzilla.gnome.org/show_bug.cgi?id=304415

Thunderbird/Enigmail

• Investigated by kees

Enigmail in Maverick correctly verifies SHA512-signed messages of all types.

Enigmail in Lucid correctly creates and validates encrypted (and signed) messages of all types, but does not perform validation of PGP/MIME messages that are only signed.

Signing a new message will use GnuPG defaults correctly.

Application Review Template

• Investigate by your-lp-id-here

Maverick

Lucid

• listed here