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 (only if you will use caff):

  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 --default-new-key-algo rsa4096)

• 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)

  • The operation may imply a delay, but its completeness can be verified with gpg --keyserver hkp://keyserver.ubuntu.com --search-key YOUREMAILADDRESS.

• 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://launchpad.net/people/+me/+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 (aka hash algorithm) is not "2" (SHA1). For SHA512, you'd want "10" (see RFC4880 section 9.4 for details):

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

  • You can validate the cipher (symmetric key) algorithm of an encrypted message is AES256 by using gpg -o /dev/null --show-session-key < ENCFILE, and checking that the algorithm is "9" (AES256, see RFC4880 section 9.2 for details). The cipher is listed as an integer before the colon. Eg:

    gpg: session key: `9:5E73B30F5A8F35D8282C9F3B9EE5C4943E06D59A0E65D9AFADD5998525F792CA'

  • You can validate the public key algorithm of an encrypted message is RSA by using gpg --list-packets < ENCFILE, and checking that the algorithm is "1" (RSA (Encrypt or Sign) [HAC], see RFC4880 section 9.1 for details). Eg:

    :pubkey enc packet: version 3, algo 1, keyid 8CB1FAB0888C8DEC
            data: [4096 bits]

  • For messages both encrypted and signed, you should be able to use gpg -d -o /dev/null -v < ENCFILE to verify the public key algorithm, the digest/hash algorithm and the cipher/symmetric-key algorithm. Eg:

    gpg: encrypted with 4096-bit RSA key...
    gpg: AES256 encrypted data
    gpg: using PGP trust model
    gpg: binary signature, digest algorithm SHA512

    If that doesn't work:
    1. validate the public key algorithm as above
    2. decrypt the message
    3. validate the digest algorithm of the decrypted message (which should contain the signature) as above.

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

  • NOTE: Be careful if your new key uses the same email address, name and comment as your old key, because GnuPG will use the first key it finds in your secret keyring for signing and encrypting when not specifying a numerical ID (eg, debsign), and therefore your old key will continue to be used. You know that you will have this problem if the gpg --list-keys YOUREMAILADDRESS lists your old key first. This can be fixed in one of a few ways:

    • For each application that uses gnupg, specify the numerical KEYID of your new key (eg, 'AAAABBBB') instead of the email address. This is the safest method, but takes more work. Eg, for devscripts, create/modify ~/.devscripts to have something like:

      DEBSIGN_KEYID="AAAABBBB"

    • You can also change the order of your keyring. Eg:

      1. make a backup of ~/.gnupg with cp -a  ~/.gnupg ~/.gnupg.bak

      2. create a safe directory with mkdir -m0700 ~/gpg && cd ~/gpg

      3. export your public key with gpg --export OLDID > ~/gpg/oldpub.gpg

      4. export your secret key with gpg --export-secret-keys OLDID > ~/gpg/oldsec.gpg

      5. delete your old public and secret key with gpg --delete-secret-and-public-key OLDID

      6. import your old public key with gpg --import ~/gpg/oldpub.gpg

      7. import your old secret key with gpg --import ~/gpg/oldsec.gpg

      8. verify it worked with gpg --list-keys YOUREMAILADDRESS. Your new key should now be listed first. Compare it to your backup with gpg --no-default-keyring --keyring ~/.gnupg.bak/pubring.gpg --secret-keyring ~/.gnupg.bak/secring.gpg --list-keys YOUREMAILADDRESS

      9. if all went well, clean up the exported keys with rm -f ~/gpg/oldpub.gpg ~/gpg/oldsec.gpg && rmdir ~/gpg

      10. sign, trust and enable the old key with gpg --edit-key OLDID

    • Lastly, you can export your old public and secret key into another keyring, then delete the old keys from your default keyring (again, make backups!). This way for normal every day work your new key can be used. The main problem with this is that your mailer won't be able to decrypt email encrypted with your old key. You can access your old key with gpg by using the --keyring and --secret-keyring options, which adds these keyring to the list of available keyrings. Eg gpg --keyring pubring_OLDID.gpg --secret-keyring secring_OLDID.gpg --list-keys.

• 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

Maverick (4:4.4.6-0ubuntu1)

Lucid (4:4.4.2-0ubuntu5)

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 is confirmed to work with the strong defaults as recommended by Debian².

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

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

Kmail Setup

Since running Kmail on a non-Kubuntu install is not necessarily straightforward, here are the steps to test:

1. sudo apt-get install kmail kleopatra

2. start kmail, but skip creating an account
3. stop kmail
4. [maverick] at this point kmail will fail to start. Need to disable the Nepomuk desktop:
   • left click on the Akonadi icon in the tray
   • Configure it to disable the desktop and file indexing
5. create a new gpg key with the above. Eg:
   • mkdir -m 0700 ~/.gnupg

   • create ~/.gnupg/gpg.conf (as above), adding use-agent to the bottom

   • generate a 4096 bit RSA/RSA key (gpg --gen-key)

   • verify the strong preferences with 'gpg --edit-key <NEWID>' and 'showpref'

6. import any keys needed for verification. Eg:

   $ gpg --keyserver keyserver.ubuntu.com --recv-keys 0xDC6DC026 # kees' test email (new key)
   $ gpg --keyserver keyserver.ubuntu.com --recv-keys 0x17063E6D # kees' test email (old key)
   $ gpg --keyserver keyserver.ubuntu.com --recv-keys 0x005E81F4 # sbeattie's USN (new key)
   $ gpg --keyserver keyserver.ubuntu.com --recv-keys 0x174BF01A # jdstrand's USN (old key)

7. restart your session (to make sure gpg-agent starts)

8. start kmail (if it dies, just try again), and update the Identity. Under the Cryptography tab:
   • set the OpenPGP signing and encrypting key to your new key
   • start the Certificate Manager (kleopatra)
     • verify the new key is listed in 'Trusted Certificates'. If not, right click on it and select 'Certify this certificate'.
     • verify the imported keys are listed in 'Other Certificates'. Right click on each and 'Change Owner Trust' to be 'marginal'
     • right click on each imported key and 'Certify Certificate' for all email addresses, being sure to 'Certify only for myself'
9. add a new email account for whatever is appropriate for your environment
   • when KWallet comes up, use 'Basic settings' but leave 'Yes, I wish to use KDE wallet to store my personal information' unchecked. Then click, 'Do not store password'.

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

Maverick (thunderbird 3.1.4+build2+nobinonly-0ubuntu3, enigmail 2:1.1.2-0ubuntu1)

Lucid (thunderbird 3.0.8+build2+nobinonly-0ubuntu0.10.04.1, enigmail 2:1.0.1-0ubuntu1)

Application Review Template

For sig checking, see this test mbox.

• Investigate by your-lp-id-here

Maverick (VERSION)

Lucid (VERSION)

• listed here