Let's Talk About Killing PGP

There’s been renewed talk on the internet recently about killing off Pretty Good Privacy, aka PGP, once and for all. (If you’re having Déjà-vu, I don’t blame you.) I think this is well-intentioned, but because there’s a huge, legacy ecosystem around “PGP,” both its defenders and the folks proposing replacements seem to be talking past each other. Without trying too hard to advocate whether “PGP” is good or bad, this post can hopefully set out some common context for both sides.

First, I think some definitions are in order:

1. There’s PGP-as-a-file-format, aka OpenPGP, aka RFC 4880. It’s supported by GnuPG, but also libraries such as OpenPGP.js or golang.org/x/crypto/openpgp. (I have code which uses the latter to verify signatures on Debian packages and Git commits.)

2. There’s the GNU Privacy Guard, aka GnuPG, the implementation-du-jour of the OpenPGP standard. It comes with gpg-agent and scdaemon, for talking to hardware tokens (e.g. Yubikeys or Nitrokeys). gpg-agent --enable-ssh-support is (AFAIK) the only open source way to use a smart card to authenticate to a remote SSH server; it works with both OpenSSH and Dropbear.

   Because we keep—quite reasonably—telling developers not to implement their own cryptography, a lot of programs depend on GnuPG for signing or encrypting data. Git’s commit and tag signing mechanisms shell out to /usr/bin/gpg. The Debian project and others have written a lot of tooling that depends on GnuPG to maintain the integrity of software packages. Lots of mail clients (e.g. Thunderbird) have plugins which use GnuPG’s API, GPGme, aka “GnuPG Made Easy.”

3. Finally, there’s the PGP ecosystem “web of trust”, i.e. the keyservers. This is designed as a way to bootstrap secure communication between two people who have never exchanged keys before; it’s the same basic goal as the x.509 Certificate Authority ecosystem used by the browsers.

So why do we want to kill it off?

RFC 4880 is not a very elegant or modern file format, and there are some painful edge cases around legacy cruft which dates back to the early 1990s. We know a lot more about how to design and implement secure cryptosystems nowadays. Even GnuPG has thrown up its hands at dealing some of these issues; GnuPG 2.x drops support for a bunch of older packet types. (As a practical matter, I have to keep a copy of GnuPG 1.x around to access my backups from before 2008 or so.)

Fully supporting RFC 4880 means supporting a bunch of older algorithms which are no longer recommended for use. There are some major footguns, such as the fact that it’s possible to encrypt a message but not authenticate it - a huge no-no.

Because RFC 4880 doesn’t support any sort of forward secrecy, let alone post-compromise security, it’s not a good protocol (by today’s standards) for secure messaging. The usual advice—practically a trope now—is to instead use something like Signal, although I’m much more excited about the Noise Protocol Framework and the work coming out of the IETF on development of an open, interopable standard for secure messaging.

(As a side note, does anyone remember when the Department of Defense wanted to build a network that would survive a nuclear war? They failed.)

There have been efforts to update RFC 4880, but the most recent one fizzled out after the folks working on it were unable to obtain any sort of consensus on the various proposals. This should perhaps serve as a cautionary tale to people currently proposing replacements.

So we have a widely-deployed standard that noone really likes. But everyone knows what happens when you try to replace a standard.

What about GnuPG?

Regardless of how you feel about RFC 4880, GnuPG’s implementation of it is no shining pinnacle of modern software development. There are a lot of valid concerns around its usability, e.g. arcane commandline options. It was written as a drop-in replacement for commercial PGP implementations, which pre-date the Linux operating system.

There was a crisis a while back when the lone person maintaining GnuPG threatened to retire, until a bunch of folks stepped in with donations to help fund continuing development. The software is still being maintained, but it is definitely not thriving.

GnuPG is written in C, so a lot of us would like to see a replacement written in a modern, memory-safe language such as Rust or Go. Like any other software dating back to 1991, it’s had its share of CVEs, but it’s been many years since the last known bounds check issue. The most recent well-publicized flaw was arguably more of an issue with clients using the API, such as Enigmail, than with GnuPG itself.

But the keyservers are under attack!

I’m old, so maybe noone else remembers back when running an open SMTP mail relay was common courtesy. It’s 2019, and nobody does that any more.

Except… some widely-used keyservers blindly accept any signature uploaded to them, and relay those signatures to the others. And they don’t have any way to delete obvious spam. And they are now virtually unusable because of this design. There are some good anti-censorship reasons for this particular design choice, but there are also some bad excuses around legacy code and functional programming languages(!).

There do exist key distribution methods such as Keybase, which don’t suffer from this problem, and it’s always been possible to exchange keys out-of-band without using a keyserver. But I wish there were better open-source options here, as I don’t relish the thought of a future where we’re all beholden to commercial interestsfor our online identity.

So what does it mean to “kill PGP?”

I’m not 100% sure, which is why I wrote this post. Is anyone working on a modern, interoperable format for signing and encrypting data at rest, similar to what the IETF is doing with MLS for messages in transit? Is anyone offering to rewrite GnuPG, but maintaining compatibility with RFC 4880? Is there a better, open source, federated approach to key distribution than the current keyserver network? (My guess is this last one is probably the easiest to solve.)

Any of these seem laudable goals. I’d love to work with you on one or all of them, and I’m probably not alone in that regard. If you’re working on a solution, let me know! PGP-encrypted mail is of course welcome.