GPGMigration

Revision 16 as of 2010-09-28 16:00:54

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":
```
: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.

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

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

Evolution

Investigated by mdeslaur

Evolution in Lucid and Maverick correctly verify SHA512-signed messages.

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.

More information is available in the upstream bug:

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

Ubuntu Wiki