Goodbye PGP
Introduction
I often do research for my journal entries and decide to change or delete them based on what I learn during the writing process. The original title of this entry was actually “The Right Way to Use PGP”. After researching PGP more, I came to the conclusion that it’s not worth using, which led me to write the Statement of GPG Key Transition.
To keep my Statement of GPG Key Transition concise, I gave no explanation of why I was abandoning PGP. Since it’s uncommon for PGP users to just abandon their key, I still want to provide that explanation, which is why I’m writing this.
Problems With PGP
I’ll proceed giving my reasons for dumping PGP, in no particular order.
The Web of Trust
To start with, PGP’s Web of Trust (WoT) is a metadata disaster, leaking all contacts to all other contacts. It’s barely used and has other drawbacks I won’t repeat as they’ve already been mentioned in the Tor Project mailing lists.
Any cryptographic tool that leaks your contacts without a disclaimer and calls it a feature is bad.
Keyservers
Now let’s talk about keyservers since they go hand-in-hand with the WoT.
Signature Spamming
If your key is on a public keyserver, anybody can generate infinite junk keys to sign yours, making your key unusably bloated. This has led respectable organizations to completely abandon public keyservers in favor of trusted keyservers.
While trusted keyservers are better than public ones, they don’t scale. For example, if Gmail were to implement a trusted keyserver, it would be easy to create multiple free accounts to spam a target key.
One way to solve signature spamming while retaining the WoT is to have key owner’s manually approve new signatures. Keyservers have instead responded by disallowing 3rd-party signatures on keys, nullifying the WoT.
If you use PGP normally, avoiding keyservers is very hard. How else will you know if someone’s key gets revoked? Without keyservers, you won’t know, which defeats the whole purpose of PGP.
Keyring Leakage
Keyservers are also a metadata disaster. Every time you request keys from a keyserver, the keyserver sees your IP and every key you request.
To protect your contact list from the keyserver, you have to install Parcimonie, separate software that refreshes each key in your keyring over Tor at randomized intervals. By the way, Parcimonie hasn’t been updated in over a year and a half.
Hopefully all your contacts use Parcimonie too. Otherwise they leak their association with you every time they pull your key. Probably less than 1% of GPG users use it, so your whole keyring is still being leaked no matter what. Sorry.
Broken Crypto
OpenPGP sacrifices security in the name of backwards-compatibility and standards compliance. It supports broken/outdated algorithms like SHA-1, 3DES, CAST5, and Blowfish. It uses CFB mode and S2K password hashing, which no modern cryptosystem should use.
Key Expiry
By default, GPG sets an expiration date on newly generated keys. It’s considered good practice, but it forces your contacts to renew your key regularly. Again, that means using a keyserver and leaking their association with you.
RSA By Default
Now let’s talk about PGP key material. Rather than using the faster, smaller, more secure Curve25519, GPG defaults to 3072-bit RSA.
Key IDs and Fingerprints
Many users still have v3 keys, which are insecure because v3 uses spoofable key IDs. But even modern v4 keys rely on SHA-1, a broken cryptographic primitive.
This makes PGP software more error-prone since fingerprints aren’t unique, it decreases key longevity, and potentially leaves you open to attack.
Packet Format
PGP also uses a variable length packet format which has caused problems in some implementations.
Compression + Encryption
The OpenPGP format combines compression and encryption which is a very bad idea. Depending on the context, it may help an attacker decipher your encrypted messages.
No Deniability
PGP does not have cryptographic deniability even though it could be implemented. Anyone who receives a signed message from you can prove to others you sent it.
For email encryption, it hardly even matters that PGP lacks deniability. Any half decent email server uses DKIM anyways, which can and has been used to prove email provenance. Unless your email provider rotates and publishes DKIM keys, and most don’t, then your emails aren’t deniable.
There’s also contextual information in the email content along with metadata and IP logs that prove your emails are yours. So the addition of a PGP signature probably doesn’t make a practical difference.
If it still bothers you, you can use a regularly rotated signing subkey and publish the private part after it’s rotated out. If you do that, you should set an expiry date so those who don’t update your subkey aren’t fooled by fake signatures.
Of course rotating PGP subkeys is a pain in the ass for you and your correspondents, so you might be better off just not signing your emails.
Lack of Forward Secrecy
The email provider cartel comprised of Gmail, Outlook, Yahoo, Aol, and others collect and store emails forever. Even if you delete your emails from the trash folder, the major email providers keep copies that are provided to law enforcement at request and sent directly to the NSA. See XKeyscore.
This means if your PGP key is ever compromised, all your emails can be retroactively decrypted. PGP isn’t solely to blame though. Email is partially responsible. But if PGP had forward secrecy, email surveillance wouldn’t be as bad.
Like signing keys, you can manually rotate encryption subkeys to protect past emails, but it’s also a pain in the ass and requires all your contacts to constantly update your key through keyservers.
No Message Padding
If that’s not enough to convince you not to use PGP for messaging, let me give you another reason. PGP uses CFB, a padding-less encryption mode. That means the exact length of the encrypted message can be recovered by attackers without decrypting the message.
If you use PGP for email, you should at least use PGP/MIME to hide attachment file types. Leaking file type and length is bad, but leaking length alone is still pretty bad since it can be used to infer file and message content.
PGP is also unsuitable for automated decryption since it’s vulnerable to padding oracle attacks.
Lack of Use Cases
Now let’s talk about how PGP’s flaws affects its use cases. In summary, it does everything poorly. For every use case, there’s a better application-specific tool for the job.
Secure Messaging
With its lack of forward secrecy and deniability, dated cryptography, lack of message padding, metadata leakage, and no proper authenticated encryption, PGP is unsuitable for the secure messaging use case. You’re better off using an application that incorporates the Double Ratchet.
File Encryption/Signing
It’s bad at file encryption and signing too. You’re better off using Age for files and LUKS for encrypted disks and backups.
You might need to keep GPG installed to verify others’ software packages. But please don’t sign your own releases with GPG. Use Signify instead.
The Web of Trust
PGP’s WoT is a good example of a non-use case. As I already mentioned, the WoT leaks the user’s social graph. Experts mistrust it. It’s heavily dependent on keyservers. Nobody uses it, so key signing parties have no practical function other than being a computer nerd circlejerk.
In conclusion, the PGP WoT needs no alternative implementation because the trust model is fundamentally flawed. It’s lack of use is a testament to its uselessness.
Digital Identity
In general, PGP’s whole notion of digital identity offers very limited usefulness.
Since nobody uses the WoT, PGP users most often trust on first use, discovering others’ keys through public forums, blogs, websites, emails, social media, etc. In the event of account compromise, visitors can be led to phony keys.
Users who already possess the correct key won’t know what to do post-compromise. Why has the key changed? Why isn’t it being used to sign things anymore? Will anybody even notice? If I announce that I’m traveling without my key and can’t sign journal entries, would you believe it? What if I claim my key is lost and I can’t revoke it?
Even if you mistrust everything that isn’t signed, most people can be coerced through violence into forking over their private key. How do you know that hasn’t happened?
I’m not saying long-term identity keys are useless. I have one myself. I’m also not blaming PGP for people not securing their accounts. I’m just pointing out long-term keys aren’t as useful as people think for a form of digital identity.
GPG protects long-term identity keys by allowing users to have online subkeys, which frees up the primary key to be kept offline. But it’s not clear to me that subkeys are necessary. Why not use a single key kept on dedicated hardware like a Yubikey? GPG’s implementation of subkeys can certainly be improved. It’s so lacking that it forces some users to rely on multiple keys.
SSH
For the SSH use case, the GPG agent can be used for SSH authentication. However, OpenSSH already provides a remote login client capable of key generation that comes preinstalled on popular Linux distros.
The OpenSSH server also doesn’t have a concept of key revocation or expiry. It can’t because that might leave clients locked out. Revoking compromised keys does nothing to stop attackers from SSH-ing into servers, which may cause confusion.
Password Management
For password management, there’s no reason to use GPG either. The standard Unix password manager Pass depends on GPG2, but there’s a fork of it called Passage which uses Age instead.
There are also other password managers which don’t depend on PGP or Age and they support a command-line interface just like Pass and Passage. Again, PGP isn’t needed for this use case.
Organizational Security
OpenPGP CA is PGP software for organizations. It uses sequoia-pgp, which seems to be an improvement over GPG.
For intraorganizational communication, there are so many secure messaging platforms which are better than PGP over Email. No organization should rely on PGP over email for internal communications. Period.
There are already mature identity management systems for organizations such as OpenLDAP. I’m no sysadmin but I’m sure there’s plenty of non-PGP dependent software which can meet organizational needs.
Application Development
When developing applications that require cryptography, there are libraries like Libsodium. It’s modern, portable, easy to use, and just better. There’s no excuse for including PGP in a new application.
As for the encrypted email use case, PGP is pretty much the only way to send end-to-end encrypted emails right now, thanks to the Network Effect.
If you have no other choice but to use email and you use PGP to encrypt, I won’t fault you for it. It’s what’s available and widely used. But do it at your own risk.
Thanks to the reckless infinite scope of the web, it’s common for emails to have embedded HTML. Please don’t embed HTML when you send emails. Popular email clients now ship with web engines, bringing all the web’s stupidity to email. This has led to several web-related PGP vulnerabilities in email clients. See Efail.
Conclusion
With that, I think I’ve covered good alternatives for all the primary use cases of PGP.
If PGP were released today, it wouldn’t be used. The only reasons it’s used are:
- It has been grandfathered in.
- The network effect keeps it going.
It’s archaic. It’s insecure. Everything it does, it does poorly. The reference implementation (GPG) is a mess. And there are better alternatives. So I’m done using it and I’m embarrassed it took me this long to stop.
Goodbye PGP.