Cryptography engineers have been tearing their hair out over PGP’s deficienciesfor (literally) decades. When other kinds of engineers get wind of this,they’re shocked. PGP is bad? Why do people keep telling me to use PGP? Theanswer is that they shouldn’t be telling you that, because PGP is bad and needsto go away.
There are, as you’re about to see, lots of problems with PGP. Fortunately, ifyou’re not morbidly curious, there’s a simple meta-problem with it: it wasdesigned in the 1990s, before serious modern cryptography. No competent cryptoengineer would design a system that looked like PGP today, nor tolerate most ofits defects in any other design. Serious cryptographers have largely given upon PGP and don’t spend much time publishing on it anymore(with a notable exception).Well-understood problems in PGP have gone unaddressed for over a decade becauseof this.
Two quick notes: first, we wrote this for engineers, not lawyers and activists.Second: “PGP” can mean a bunch of things, from theOpenPGP standardto its referenceimplementation in GnuPG. We use the term “PGP” to cover all of these things.
The Problems
Absurd Complexity
For reasons none of us here in the future understand, PGP has a packet-basedstructure. A PGP message (in a “.asc” file) is an archive of typed packets.There areat least 8 different waysofencoding the length of a packet, depending on whether you’re using “new” or“old” format packets. The “new format” packets have variable-length lengths,like BER (try to write a PGP implementation and you may wish for the sweetrelease of ASN.1). Packets can have subpackets. There are overlapping variantsof some packets. The most recent keyserver attack happened because GnuPGaccidentally went quadraticin parsing keys, which also follow this deranged format.
That’s just the encoding. The actual system doesn’t get simpler. There are keysand subkeys. Key IDs and key servers and key signatures. Sign-only andencrypt-only. Multiple “key rings”. Revocation certificates. Three differentcompression formats. This is all before we get to smartcard support.
Swiss Army Knife Design
If you’re stranded in the woods and, I don’t know, need to repair your jeancuffs, it’s handy if your utility knife has a pair of scissors. But nobody whodoes serious work uses their multitool scissors regularly.
A Swiss Army knife does a bunch of things, all of them poorly. PGP does amediocre job of signing things, a relatively poor job of encrypting them withpasswords, and a pretty bad job of encrypting them with public keys. PGP is notan especially good way to securely transfer a file. It’s a clunky way to signpackages. It’s not great at protecting backups. It’s a downright dangerous wayto converse in secure messages.
Back in the MC Hammer era from which PGP originates, “encryption” was its ownspecial thing; there was one tool to send a file, or to back up a directory,and another tool to encrypt and sign a file. Modern cryptography doesn’t worklike this; it’s purpose built. Secure messaging wants crypto that is differentfrom secure backups or package signing.
Mired In Backwards Compatibility
PGP predates modern cryptography; there are Hanson albums that have agedbetter. If you’re lucky, your local GnuPG defaults to 2048-bit RSA, the64-bit-block CAST5 cipher in CFB, and the OpenPGP MDC checksum (about whichmore later). If you encrypt with a password rather than with a public key, theOpenPGP protocol specifies PGP’s S2K password KDF. These are, to put it gently,not the primitives a cryptography engineer would select for a modern system.
We’ve learned a lot since Steve Urkel graced the airwaves during ABC’s TGIF:that you should authenticate your ciphertexts (and avoid CFB mode) would be anobvious example, but also that 64-bit block ciphers are bad, that we can domuch better than RSA, that mixing compression and encryption is dangerous, andthat KDFs should be both time- and memory-hard.
Whatever the OpenPGP RFCs may say, you’re probably not doing any of thesethings if you’re using PGP, nor can you predict when you will. Take AEADciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode,which is great, and nobody can read those messages because most PGP installsdon’t know what EAX mode is, which is not great. Every well-known badcryptosystem eventually sprouts an RFC extension that supports curves or AEAD,so that its proponents can claim on message boards that they support moderncryptography. RFC’s don’t matter: only the installed base does. We’veunderstood authenticated encryption for 2 decades, and PGP is old enough to buyme drinks; enough excuses.
You can have backwards compatibility with the 1990s or you can have soundcryptography; you can’t have both.
Obnoxious UX
We can’t say this any better than Ted Unangst:
There was a PGP usability study conducted a few years ago where a group oftechnical people were placed in a room with a computer and asked to set upPGP. Two hours later, they were never seen or heard from again.
If you’d like empirical data of your own to back this up, here’s an experimentyou can run: find an immigration lawyer and talk them through the process ofgetting Signal working on their phone. You probably don’t suddenly smellburning toast. Now try doing that with PGP.
Long-Term Secrets
PGP begs users to keep a practically-forever root key tied to their identity.It does this by making keys annoying to generate and exchange, by encouraging“key signing parties”, and by creating a “web of trust” where keys depend onother keys.
Long term keys are almost never what you want.If you keep using a key, it eventually gets exposed. You want the blast radiusof a compromise to be as small as possible, and, just as importantly, you don’twant users to hesitate even for a moment at the thought of rolling a new key ifthere’s any concern at all about the safety of their current key.
The PGP cheering section will immediately reply “that’s why you keep keys on aYubikey”. To a decent first approximation, nobody in the whole world uses theexpensive Yubikeys that do this, and you can’t imagine a future in which thatchanges (we can barely get U2F rolled out, and those keys are disposable). Wecan’t accept bad cryptosystems just to make Unix nerds feel better about theirtoys.
Broken Authentication
More on PGP’s archaic primitives: way back in 2000, the OpenPGP working grouprealized they needed to authenticate ciphertext, and that PGP’s signaturesweren’t accomplishing that. So OpenPGP inventedthe MDC system: PGPmessages with MDCs attach a SHA-1 of the plaintext to the plaintext, which isthen encrypted (as normal) in CFB mode.
If you’re wondering how PGP gets away with this when modern systems userelatively complex AEAD modes (why can’t everyone just tack a SHA-1 to theirplaintext), you’re not alone. Where to start with this Rube Goldbergcontraption? The PGP MDC can be stripped off messages –– it was encoded in sucha way that you can simply chop off the last 22 bytes of the ciphertext to dothat. To retain backwards compatibility with insecure older messages, PGPintroduced a new packet type to signal that the MDC needs to be validated; ifyou use the wrong type, the MDC doesn’t get checked. Even if you do, the newSEIP packet format is close enough to the insecure SE format that you canpotentially trick readers into downgrading;Trevor Perrin worked the SEIP out to 16 whole bits of security.
And, finally, even if everything goes right, the reference PGP implementationwill (wait for it) release unauthenticated plaintext to callers, even if theMDC doesn’t match.
Incoherent Identity
PGP is an application. It’s a set of integrations with other applications. It’sa file format. It’s also a social network, and a subculture.
PGP pushes notion of a cryptographic identity. You generate a key, save it inyour keyring, print its fingerprint on your business card, and publish it to akeyserver. You sign other people’s keys. They in turn may or may not rely onyour signatures to verify other keys. Some people go out of their way to meetother PGP users in person to exchange keys and more securely attach themselvesto this “web of trust”. Other people organize “key signing parties”. The imageyou’re conjuring in your head of that accurately explains how hard it is toPGP’s devotees to switch to newer stuff.
None of this identity goop works. Not the key signing web of trust, not thekeyservers, not the parties. Ordinary people will trust anything that lookslike a PGP key no matter where it came from – how could they not, when even anexpert would have a hard time articulating how to evaluate a key? Experts don’ttrust keys they haven’t exchanged personally. Everyone else relies oncentralized authorities to distribute keys. PGP’s key distribution mechanismsare theater.
Leaks Metadata
Forget the email debacle for a second (we’ll get to that later). PGP by itselfleaks metadata. Messages are (in normal usage) linked directly to keyidentifiers, which are, throughout PGP’s cobweb of trust, linked to useridentity. Further, a rather large fraction of PGP users make use of keyservers,which can themselves leak to the network the identities of which PGP users arecommunicating with each other.
No Forward Secrecy
A good example of that last problem: secure messaging crypto demands forwardsecrecy. Forward secrecy means that if you lose your key to an attacker today,they still can’t go back and read yesterday’s messages; they had to be therewith the key yesterday to read them. In modern cryptography engineering, weassume our adversary is recording everything, into infinite storage. PGP’sclaimed adversaries include world governments, many of whom are certainly doingexactly that. Against serious adversaries and without forward secrecy, breachesare a question of “when”, not “if”.
To get forward secrecy in practice, you typically keep two secret keys: a shortterm session key and a longer-term trusted key. The session key is ephemeral(usually the product of a DH exchange) and the trusted key signs it, so that aman-in-the-middle can’t swap their own key in. It’s theoretically possible toachieve a facsimile of forward secrecy using the tools PGP provides. Of course,pretty much nobody does this.
Clumsy Keys
An OpenBSD signify(1) public key is a Base64 string short enough to fit in themiddle of a sentence in an email; the private key, which isn’t an interchangeformat, is just a line or so longer. A PGP public key is a whole giant Base64document; if you’ve used them often, you’re probably already in the habit ofattaching them rather than pasting them into messages so they don’t getcorrupted. Signify’s key is a state-of-the-art Ed25519 key; PGP’s is a weakerRSA key.
You might think this stuff doesn’t matter, but it matters a lot; orders ofmagnitude more people use SSH and manage SSH keys than use PGP. SSH keys aretrivial to handle; PGP’s are not.
Negotiation
PGP supports ElGamal. PGP supports RSA. PGP supports the NIST P-Curves. PGPsupports Brainpool. PGP supports Curve25519. PGP supports SHA-1. PGP supportsSHA-2. PGP supports RIPEMD160. PGP supports IDEA. PGP supports 3DES. PGPsupports CAST5. PGP supports AES. There is no way this is a complete list ofwhat PGP supports.
If we’ve learned 3 important things about cryptography design in the last 20years, at least 2 of them are that negotiation and compatibility are evil. Theflaws in cryptosystems tend to appear in the joinery, not the lumber, andexpansive crypto compatibility increases the amount of joinery. Modernprotocols like TLS 1.3 are jettisoning backwards compatibility with things likeRSA, not adding it. New systems support just a single suite of primitives,and a simple version number. If one of those primitives fails, you bump theversion and chuck the old protocol all at once.
If we’re unlucky, and people are still using PGP 20 years from now, PGP will bethe only reason any code anywhere includes CAST5. We can’t say this moreclearly or often enough: you can have backwards compatibility with the 1990s oryou can have sound cryptography; you can’t have both.
Janky Code
The de facto standard implementation of PGP is GnuPG. GnuPG is not carefullybuilt. It’s a sprawling C-language codebase with duplicative functionality(write-ups of the most recent SKS key parsing denial of service noted that ithas multiple key parsers, for instance) with along track record of CVEsranging from memory corruption to cryptographic side channels. It has at timesbeen possible to strip authenticators off messages without GnuPG noticing. It’sbeen possible to feed it keys that don’t fingerprint properly without itnoticing. The 2018 Efail vulnerability was a result of it releasingunauthenticated plaintext to callers. GnuPG is not good.
GnuPG is also effectively the reference implementation for PGP, and also thebasis for most other tools that integrate PGP cryptography. It isn’t goinganywhere. To rely on PGP is to rely on GPG.
The Answers
One of the rhetorical challenges of persuading people to stop using PGP is thatthere’s no one thing you can replace it with, nor should there be. What youshould use instead depends on what you’re doing.
Talking To People
Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based securemessenger.
Modern secure messengers are purpose-built around messaging. They useprivacy-preserving authentication handshakes, repudiable messages,cryptographic ratchets that rekey on every message exchange, and, of course,modern encryption primitives. Messengers are trivially easy to use and there’sno fussing over keys and subkeys. If you use Signal, you get even more thanthat: you get a system so paranoid about keeping private metadata off serversthat it tunnels Giphy searches to avoid traffic analysis attacks, and untilrelatively recently didn’t even support user profiles.
Encrypting Email
Don’t.
Email is insecure. Even withPGP, it’s default-plaintext, which means that even if you do everything right,some totally reasonable person you mail, doing totally reasonable things, willinvariably CC the quoted plaintext of your encrypted message to someone else(we don’t know a PGP email user who hasn’t seen this happen). PGP email isforward-insecure. Email metadata, including the subject (which is literallymessage content), are always plaintext.
If you needed another reason,read the Efail paper.The GnuPG community,which mishandled the Efail disclosure,talks this research down a lot, but it was accepted at Usenix Security (one ofthe top academic software security venues) and at Black Hat USA (the topindustry software security venue), was one of the best cryptographic attacks ofthe last 5 years, and is a pretty devastating indictment of the PGP ecosystem.As you’ll see from the paper, S/MIME isn’t better.
This isn’t going to get fixed. To make actually-secure email, you’d have totunnel another protocol over email (you’d still be conceding traffic analysisattacks). At that point, why bother pretending?
Encrypting email is asking for a calamity. Recommending email encryption toat-risk users is malpractice. Anyone who tells you it’s secure to communicateover PGP-encrypted email is putting their weird preferences ahead of yoursafety.
Sending Files
Use Magic Wormhole. Wormholeclients use a one-time password-authenticated key exchange (PAKE) to encryptfiles to recipients. It’s easy (for nerds, at least), secure, and fun: wehaven’t introduced wormhole to anyone who didn’t start gleefully wormholingthings immediately just like we did.
Someone stick a Windows installer on a Go or Rust implementation of MagicWormhole right away; it’s too great for everyone not to have.
If you’re working with lawyers and not with technologists, Signal does aperfectly cromulent job of securing file transfers. Put a Signal number on yoursecurity page to receive bug bounty reports, not a PGP key.
Encrypting Backups
Use Tarsnap.Colin can tell you all about how Tarsnap is optimized to protect backups.Or really, use any other encrypted backup tool that lots of other people use;they won’t be as good as Tarsnap but they’ll all do a better job than PGP will.
Need offline backups? Use encrypted disk images; they’re built into modernWindows, Linux, and macOS.Full disk encryption isn’t great,but it works fine for this use case, and it’s easier and safer than PGP.
Signing Packages
Use Signify/Minisign.Ted Unangst will tell you all about it.It’s what OpenBSD uses to sign packages. It’s extremely simple and uses modernsigning. Minisign, from Frank Denis,the libsodium guy, brings the same design to Windows and macOS; it has bindingsfor Go, Rust, Python, Javascript, and .NET; it’s even compatible with Signify.
Encrypting Application Data
Use libsodiumIt builds everywhere,has interface that’s designed to be hard to misuse, and you won’t have to shellout to a binary to use it.
Encrypting Files
This really is a problem. If you’re/not/making a backup, and you’re/not/archiving something offline for long-term storage, and you’re/not/encrypting in order to securely send the file to someone else, and you’re/not/encrypting virtual drives that you mount/unmount as needed to get workdone, then there’s no one good tool that does this now. Filippo Valsorda isworking on“age”for these use cases, and I’m super optimistic about it, but it’s not there yet.
Update, February 2020
Filippo’s agehas been released. It’s a soliddesign with simple, easily auditable implementations in Go and Rust. You canbuild binaries for it for every mainstream platform. Age is, of course, muchyounger than PGP. But I would bet all the money in my pocket against all themoney in yours that a new vulnerability will be found in the clangorouscontraption of PGP before one is found in age. Look into age!
Hopefully it’s clear that this is a pretty narrow use case. We work in softwaresecurity and handle sensitive data, including bug bounty reports (another supercommon “we need PGP!” use case), and we almost never have to touch PGP.
