Neal H. Walfield is a hacker at g10code working on GnuPG. This op-ed was written for Ars Technica by Walfield, in response to Filippo Valsorda's " I'm giving up on PGP " story that was published on Ars last week.

Every once in a while, a prominent member of the security community publishes an article about how horrible OpenPGP is. Matthew Green wrote one in 2014 and Moxie Marlinspike wrote one in 2015. The most recent was written by Filippo Valsorda, here on the pages of Ars Technica, which Matthew Green says "sums up the main reason I think PGP is so bad and dangerous."

In this article I want to respond to the points that Filippo raises. In short, Filippo is right about some of the details, but wrong about the big picture. For the record, I work on GnuPG, the most popular OpenPGP implementation.

Forward secrecy isn't always desirable

Filippo's main complaint has to do with OpenPGP's use of long-term keys. Specifically, he notes that due to the lack of forward secrecy, the older a key is, the more communication will be exposed by its compromise. Further, he observes that OpenPGP's trust model includes incentives to not replace long-term keys.

First, it's true that OpenPGP doesn't implement forward secrecy (or future secrecy). But, OpenPGP could be changed to support this. Matthew Green and Ian Miers recently proposed puncturable forward secure encryption, which is a technique to add forward secrecy to OpenPGP-like systems. But, in reality, approximating forward secrecy has been possible since OpenPGP adopted subkeys decades ago. (An OpenPGP key is actually a collection of keys: a primary key that acts as a long-term, stable identifier, and subkeys that are cryptographically bound to the primary key and are used for encryption, signing, and authentication.)

Guidelines on how to approximate forward secrecy were published in 2001 by Ian Brown, Adam Back, and Ben Laurie. Although their proposal is only for an approximation of forward secrecy, it is significantly simpler than Green and Miers' approach, and it works in practice.

As far as I know, Brown et al.'s proposal is not often used. One reason for this is that forward secrecy is not always desired. For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future. If you use forward secrecy, then, by definition, that is not possible; you've thrown away the old decryption key. In the recent past, I've spoken with a number of GnuPG users including 2U and 1010data. These two companies told me that they use GnuPG to protect client data. Again, to access the data in the future, the encryption keys need to be retained, which precludes forward secrecy.

This doesn't excuse the lack of forward secrecy when using GnuPG to protect e-mail, which is the use case that Filippo concentrates on. The reason that forward secrecy hasn't been widely deployed here is that e-mail is usually left on the mail server in order to support multi-device access. Since mail servers are not usually trusted, the mail needs to be kept encrypted. The easiest way to accomplish this is to just not strip the encryption layer. So, again, forward secrecy would render old messages inaccessible, which is often not desired.

But, let's assume that you really want something like forward secrecy. Then following Brown et al.'s approach, you just need to periodically rotate your encryption subkey. Since your key is identified by the primary key and not the subkey, creating a new subkey does not change your fingerprint or invalidate any signatures, as Filippo states. And, as long as your communication partners periodically refresh your key, rotating subkeys is completely transparent.

Ideally, you'll want to store your primary key on a separate computer or smartcard so that if your computer is compromised, then only the subkeys are compromised. But, even if you don't use an offline computer, and an attacker also compromises your primary key, this approach provides a degree of future secrecy: your attacker will be able to create new subkeys (since she has your primary key), and sign other keys, but she'll probably have to publish them to use them, which you'll eventually notice, and she won't be able to guess any new subkeys using the existing keys.

Physical attacks vs. cyber attacks

So, given that forward secrecy is possible, why isn't it enabled by default? We know from Snowden that when properly implemented, "encryption … really is one of the few things that we can rely on." In other words, when nation states crack encryption, they aren't breaking the actual encryption, they are circumventing it. That is, they are exploiting vulnerabilities or using national security letters (NSLs) to break into your accounts and devices. As such, if you really care about protecting your communication, you are much better off storing your encryption keys on a smartcard then storing them on your computer.

Given this, it's not clear that forward secrecy is that big of a gain, since smartcards won't export private keys. So, when Filippo says that he is scared of an evil maid attack and is worried that someone opened his safe with his offline keys while he was away, he's implicitly stating that his threat model includes a physical, targeted attack. But, while moving to the encrypted messaging app Signal gets him forward secrecy, it means he can't use a smartcard to protect his keys and makes him more vulnerable to a cyber attack, which is significantly easier to conduct than a physical attack.

Another problem that Filippo mentions is that key discovery is hard. Specifically, he says that key server listings are hard to use. This is true. But, key servers are in no way authenticated and should not be treated as authoritative. Instead, if you need to find someone's key, you should ask that person for their key's fingerprint. Unfortunately, our research suggests that for many GnuPG users, picking up the phone is too difficult.

So, after our successful donation campaign two years ago, we used some of the money to develop a new key discovery technique called the Web Key Directory (WKD). Basically, the WKD provides a canonical way to find a key given an e-mail address via HTTPS. This is not as good as checking the fingerprint, but since only the mail provider and the user can change the key, it is a significant improvement over the de facto status quo. WKD has already been deployed by Posteo, and other mail providers are in the process of integrating it (consider asking your mail provider to support it).

Other people have identified the key discovery issue, too. Micah Lee, for instance, recently published GPG Sync, and the INBOME group and the pretty Easy privacy (p≡p) project are working on opportunistically transferring keys via e-mail.