My take on OpenPGP best practices

After having seen a few talks at DebConf on GnuPG and related things, I would like to document here how I currently manage my OpenPGP keys, in the hope they can be useful for other people or for discussion. This is not a tutorial, meaning that I do not give you the commands to do what I am saying, otherwise it would become way too long. If there is the need to better document how to implement these best practices, I will try to write another post.

I actually do have two OpenPGP certificates, D9AB457E and E535FA6D. The first one is RSA 4096 and the second one is Curve25519. The reason for having two certificates is algorithm diversity: I don't know which one between RSA and Curve25519 will be the first to be considered less secure or insecure, therefore I would like to be ready for both scenarios. Having two certificates already allows me to do signature hunting on both, in such a way that it is easy to transition from one to the other as soon as there is the need.

The key I currently use is the RSA one, which is also the one available in the Debian keyring.

(If you search on the keyservers you will find many other keys with my name; they are obsolete, meant for my internal usage or otherwise not in use; just ignore them!)

Even if the two primary keys are different, their subkeys are the same (apart from some older cruft now revoked), meaning that they have the same key material. This is useful, because I can use the same hardware token for both keys (most hardware token only have three key slot, one for each subkey capability, so to have two primary keys ready for use you need two tokens, unless the two keys share their subkeys). I have one subkey for each subkey capability (sign, encrypt and authentication), wich are Curve25519 keys and are stored in a Nitrokey Start token. I also have, but tend to not use, one RSA subkey for each capability, which are stored on a OpenPGP card. Thanks to some date tweaking, both certificates are configured in such a way that Curve25519 subkeys are always preferred over RSA subkeys, but I also want to retain the RSA keys for corner cases where Curve25519 is not available.

The reason to choose Curve25519 over RSA for default usage is that they are faster and generate smaller signatures. I have no idea which one is considered more secure, but I believe that neither of them is the weak link in my security chain.

The primary keys have an expiration date, which is always my birthday. Such choice is for remembering, a couple of months in advance, to extend it of one year, so that the key remains valid. Choosing the update interval here is of course a compromise between security and convenience. One year seems fine. I see no advantage in setting an expiration date on subkeys, since I can always use the primary key to revoke them. It might be useful to set an expiration date if I had a subkey rotation strategy, but I don't, and unfortunately with OpenPGP is a bit difficult to have one, since all subkeys are stored forever in the certificate, which would quickly become bloated.

The primary keys' private material is stored in a external disk that is normally disconnected from any computer, so completely inaccessible from the Internet. I connect it to my computer when I need to do operations that require the primary key, like signing other keys, managing subkeys or extending the key validity. This setup is not ideal, because it would be better to only connect the external storage to a machine that is always offline (and therefore is less likely to have been compromised). But that would require maintaining another machine, and as usual one has to compromise between security and convenience. Also, that external disk also contains other data, so it gets connected to my laptop also for other operations than working with OpenPGP certificates. I could improve here, but it is still better than bringing the primary key as a file in my computer.

I also have copies of my keys' private material (both for primary keys and subkeys) and revokation certificates on a bunch of paper sheets hidden somewhere in my house, just in case the external disk should fail. A common tool for this step is paperkey, although I did follow this tutorial to encode the secret key in a number of data matrices.

Overall, while my setup is perfectible, I believe it also reasonably secure for my use case, and quite convenient to use.