I've got a new PGP keypair. The primary (certification) key has the id 59D593461D9FF82BC1D2A579C7FF8B0BACB5F9DB. Please don't use 32bit (8 character) key ids, these are insecure for many years now.

You should be able to fetch these from the SKS key server network, and from the new openpgp.org keyserver built using Sequoia PGP. Alternatively, this website also hosts a copy.

The new key is signed using my old keypair, which is now revoked.

Why?

Well, I screwed up my last key. While from a security point of view everything was probably fine, I noticed that my key backup didn't work.

I don't like having my PGP keys lying around on my filesystem, as pretty much any software (especially with root privileges) can simply steal them. Therefore, I'm exclusively using smartcards and airgapped systems to store my PGP keys. My strategy was:

  • Generate a backup keypair on an airgapped Raspberry Pi
  • Move this over to a smartcard (ordered from the excellent FLOSS Shop)
  • Make a backup of the public key on a USB thumb drive - you can't recover the public key from the smartcard!

Following that, I'm creating the actual keypair.

  • Generate a keypair on an airgapped Raspberry Pi
  • Export the secret keys, encrypting them to the backup keypair stored exclusively on the smartcard
  • Save the encrypted secret keys on a USB thumb drive
  • Move the secret keys to a YubiKey 5 (as I require NFC for my day-to-day crypto tasks)

Apparently, I've screwed up that second step and only exported the encryption subkey. Unfortunately, this means that once the YubiKey breaks or is lost, I can't manage my subkeys anymore, as the certification key is stored exclusively there.

Therefore, I've rotated my keypair, somewhat following the excellent tutorial from Daniel Pecos Martínez. This time, I recovered the keys from the backup and made sure that they are indeed working. Furthermore, I've now got 2 smartcards, a YubiKey for portable use and an ID-1 format card for desktop use. They need to share the same encryption key (which is backed up alongside the private certification key), but each smartcard has its own private signature and authentication subkey. This way, in case I lose one of those, I only need to revoke the appropriate subkey and rotate my shared encryption private key on all smartcards.

I think that this is a pretty good setup and reflects the individual hardware devices in my PGP key. Also, for devices that support it I can now also use the fast and highly controversial elliptic curves. I hope the PGP smartcards will support Ed25519 someday.