diff options
author | Nicholas Johnson <nick@nicholasjohnson.ch> | 2024-05-27 00:00:00 +0000 |
---|---|---|
committer | Nicholas Johnson <nick@nicholasjohnson.ch> | 2024-05-27 00:00:00 +0000 |
commit | 628046738b0e4f410c639dd4844925ff044c79d2fb14b0e42722f1bee733f1ad (patch) | |
tree | cc1af60eedfa34aca0c24a6f1f6edfc554b6912715dc090bc8f124527e857caf /content/entry/goodbye-pgp.md | |
parent | 46e98fe4f8c4c373ccb42427122f1fe032cc68038ec3e13dcf43dec31b874a8a (diff) | |
download | journal-628046738b0e4f410c639dd4844925ff044c79d2fb14b0e42722f1bee733f1ad.tar.gz journal-628046738b0e4f410c639dd4844925ff044c79d2fb14b0e42722f1bee733f1ad.zip |
Fix tons of links
Diffstat (limited to 'content/entry/goodbye-pgp.md')
-rw-r--r-- | content/entry/goodbye-pgp.md | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/content/entry/goodbye-pgp.md b/content/entry/goodbye-pgp.md index 372bcb5..579385e 100644 --- a/content/entry/goodbye-pgp.md +++ b/content/entry/goodbye-pgp.md @@ -5,7 +5,7 @@ tags: ['computing'] draft: 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](/2021/12/30/statement-of-gpg-key-transition). +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. @@ -53,13 +53,13 @@ Many users still have v3 keys, which are insecure because v3 uses spoofable key 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](https://nitter.net/lambdafu/status/1147162583969009664) which has caused problems in some implementations. +PGP also uses a [variable length packet format](https://x.com/lambdafu/status/1147162583969009664) which has caused problems in some implementations. ## Compression + Encryption 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](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. +PGP does not have [cryptographic deniability](https://en.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 +70,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](https://www.wikipedia.org/wiki/XKeyscore). +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://en.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,7 +81,7 @@ 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](https://www.wikipedia.org/wiki/Padding_oracle_attack). +PGP is also unsuitable for automated decryption since it's vulnerable to [padding oracle attacks](https://en.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. @@ -90,19 +90,19 @@ Now let's talk about how PGP's flaws affects its use cases. In summary, it does 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](https://github.com/FiloSottile/age) for files and [LUKS](https://www.wikipedia.org/wiki/Linux_Unified_Key_Setup) 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://en.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](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](https://www.wikipedia.org/wiki/Key_signing_party) 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://en.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](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. +Since nobody uses the WoT, PGP users most often [trust on first use](https://en.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? @@ -133,7 +133,7 @@ There are already mature identity management systems for organizations such as [ 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](https://www.wikipedia.org/wiki/Network_effect#Software). +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://en.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. |