diff options
Diffstat (limited to 'content/entry/goodbye-pgp.md')
| -rw-r--r-- | content/entry/goodbye-pgp.md | 81 |
1 files changed, 24 insertions, 57 deletions
diff --git a/content/entry/goodbye-pgp.md b/content/entry/goodbye-pgp.md index fa067f2..3d76a9f 100644 --- a/content/entry/goodbye-pgp.md +++ b/content/entry/goodbye-pgp.md @@ -2,10 +2,9 @@ title: "Goodbye PGP" date: 2022-01-03T00:00:00 draft: false -makerefs: false --- # 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.[1] +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](/2021/12/30/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. @@ -13,7 +12,7 @@ To keep my Statement of GPG Key Transition concise, I gave no explanation of why 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.[2] +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](https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html). Any cryptographic tool that leaks your contacts without a disclaimer and calls it a feature is bad. @@ -21,7 +20,7 @@ Any cryptographic tool that leaks your contacts without a disclaimer and calls i 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.[3] +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](https://mailbox.org/en/post/the-keyserver-is-dead-long-live-the-keyserver). 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. @@ -32,12 +31,12 @@ If you use PGP normally, avoiding keyservers is very hard. How else will you kno ### 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[4], 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. +To protect your contact list from the keyserver, you have to install [Parcimonie](https://manpages.debian.org/bullseye/parcimonie/parcimonie.1p.en.html), 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 -PGP also supports the NIST and Brainpool elliptic curves which many security experts believe are backdoored.[5] It shouldn't support those curves in the first place. At the very least, GPG should warn users, but it doesn't. +[PGP also supports the NIST and Brainpool elliptic curves which many security experts believe are backdoored.](https://safecurves.cr.yp.to/) It shouldn't support those curves in the first place. At the very least, GPG should warn users, but it doesn't. 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. @@ -48,18 +47,18 @@ By default, GPG sets an expiration date on newly generated keys. It's considered 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.[6] +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](https://shattered.io/). -This makes PGP software more error-prone since fingerprints aren't unique, it decreases key longevity, and potentially leaves you open to attack.[7] +This makes PGP software more error-prone since fingerprints aren't unique, it decreases key longevity, and potentially leaves you [open to attack](https://security.stackexchange.com/questions/68105/gpg-keys-sha-1). ## Packet Format -PGP also uses a variable length packet format which has caused problems in some implementations.[8] +PGP also uses a [variable length packet format](https://nitter.net/lambdafu/status/1147162583969009664) 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. +The OpenPGP format combines [compression and encryption](https://security.stackexchange.com/questions/43413/is-it-safe-for-gpg-to-compress-all-messages-prior-to-encryption-by-default) 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[9] even though it could be implemented. Anyone who receives a signed message from you can prove to others you sent it. +PGP does not have [cryptographic deniability](https://www.wikipedia.org/wiki/Deniable_encryption) 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. @@ -70,7 +69,7 @@ If it still bothers you, you can use a regularly rotated signing subkey and publ 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.[10] +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](https://www.wikipedia.org/wiki/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. @@ -81,28 +80,28 @@ If that's not enough to convince you not to use PGP for messaging, let me give y 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.[11] +PGP is also unsuitable for automated decryption since it's vulnerable to [padding oracle attacks](https://www.wikipedia.org/wiki/Padding_oracle_attack). ## 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[12]. +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](https://signal.org/docs/specifications/doubleratchet/). ### File Encryption/Signing -It's bad at file encryption and signing too. You're better off using Age[13] for files and LUKS[14] for encrypted disks and backups. +It's bad at file encryption and signing too. You're better off using [Age](https://github.com/FiloSottile/age) for files and [LUKS](https://www.wikipedia.org/wiki/Linux_Unified_Key_Setup) 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[15] instead. +You might need to keep GPG installed to verify others' software packages. But please don't sign your own releases with GPG. Use [Signify](https://man.openbsd.org/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[16] have no practical function other than being a computer nerd circlejerk. +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](https://www.wikipedia.org/wiki/Key_signing_party) 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[17], 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. +Since nobody uses the WoT, PGP users most often [trust on first use](https://www.wikipedia.org/wiki/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? @@ -110,7 +109,7 @@ Even if you mistrust everything that isn't signed, most people can be coerced th 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.[18] +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](https://zeroindexed.com/pgp-encryption-subkeys). ### 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. @@ -118,26 +117,26 @@ For the SSH use case, the GPG agent can be used for SSH authentication. However, 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[19] depends on GPG2, but there's a fork of it called Passage[20] which uses Age instead. +For password management, there's no reason to use GPG either. The standard Unix password manager [Pass](https://www.passwordstore.org/) depends on GPG2, but there's a fork of it called [Passage](https://github.com/FiloSottile/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[21] is PGP software for organizations. It uses sequoia-pgp[22], which seems to be an improvement over GPG. +[OpenPGP CA](https://openpgp-ca.org) is PGP software for organizations. It uses [sequoia-pgp](https://sequoia-pgp.org/), 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[23]. I'm no sysadmin but I'm sure there's plenty of non-PGP dependent software which can meet organizational needs. +There are already mature identity management systems for organizations such as [OpenLDAP](https://www.openldap.org/). 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[24]. It's modern, portable, easy to use, and just better. There's no excuse for including PGP in a new application. +When developing applications that require cryptography, there are libraries like [Libsodium](https://github.com/jedisct1/libsodium). It's modern, portable, easy to use, and just better. There's no excuse for including PGP in a new application. ### Email -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[25]. +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](https://www.wikipedia.org/wiki/Network_effect#Software). 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[26], it's common for emails to have embedded HTML. Please don't embed HTML when you send emails.[27] 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.[28] +Thanks to [the reckless infinite scope of the web](https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html), it's common for emails to have embedded HTML. [Please don't embed HTML when you send emails.](https://useplaintext.email/) 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](https://efail.de). # Conclusion With that, I think I've covered good alternatives for all the primary use cases of PGP. @@ -150,35 +149,3 @@ If PGP were released today, it wouldn't be used. The only reasons it's used are: 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. - - -Link(s): -[1: Statement of GPG Key Transition](/2021/12/30/statement-of-gpg-key-transition) -[2: Problems With The Web of Trust](https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html) -[3: The Keyserver is Dead. Long Live the Keyserver!](https://mailbox.org/en/post/the-keyserver-is-dead-long-live-the-keyserver) -[4: Parcimonie](https://manpages.debian.org/bullseye/parcimonie/parcimonie.1p.en.html) -[5: Safe Curves](https://safecurves.cr.yp.to/) -[6: SHAttered](https://shattered.io/) -[7: GPG Keys SHA-1](https://security.stackexchange.com/questions/68105/gpg-keys-sha-1) -[8: PGP Packet Format](https://nitter.net/lambdafu/status/1147162583969009664) -[8: PGP Compression + Encryption](https://security.stackexchange.com/questions/43413/is-it-safe-for-gpg-to-compress-all-messages-prior-to-encryption-by-default) -[9: Cryptographic Deniability](https://www.wikipedia.org/wiki/Deniable_encryption) -[10: XKeyscore](https://www.wikipedia.org/wiki/XKeyscore) -[11: Padding Oracle Attack](https://www.wikipedia.org/wiki/Padding_oracle_attack) -[12: Double Ratchet](https://signal.org/docs/specifications/doubleratchet/) -[13: Age Encryption](https://github.com/FiloSottile/age) -[14: LUKS](https://www.wikipedia.org/wiki/Linux_Unified_Key_Setup) -[15: Signify](https://man.openbsd.org/signify) -[16: Key Signing Parties](https://www.wikipedia.org/wiki/Key_signing_party) -[17: Trust On First Use](https://www.wikipedia.org/wiki/Trust_on_first_use) -[18: PGP Encryption Subkeys](https://zeroindexed.com/pgp-encryption-subkeys) -[19: Pass](https://www.passwordstore.org/) -[20: Passage](https://github.com/FiloSottile/passage) -[21: OpenPGP CA](https://openpgp-ca.org) -[22: Sequoia PGP](https://sequoia-pgp.org/) -[23: OpenLDAP](https://www.openldap.org/) -[24: Libsodium](https://github.com/jedisct1/libsodium) -[25: The Network Effect](https://www.wikipedia.org/wiki/Network_effect#Software) -[26: The Reckless, Infinite Scope of Web Browsers](https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html) -[27: Use Plaintext Email](https://useplaintext.email/) -[28: Efail](https://efail.de) |