GPG is an immense failure from the point of protecting person to person communications.
It is largely a success in verifying the identities of the software developers. The entire Debian ecosystem relies on GPG in largely successful ways.
Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication. It appears the PGP just can't be bootstrapped into modernity from a communication point of view. The only major innovation in authentication and identity has been threshold signatures which GPG could support.
It's very unfortunate PGP/GPG hasn't kept up with the times. Today it has two significant issues:
1. The needed trust model has changed significantly.
2. It's not reusable enough.
1. The original PGP mostly dealt with direct person-to-person relationships. Alice and Bob needed to safely communicate. Perhaps Bob could vouch for Carol. But that was the intended model: closely related groups, with maybe a person trusted to act as an introducer. Today our needs are different, and we need to securely communicate with people we never met, or to verify their signatures. Any Linux system contains thousands of packages, which were worked on by many thousands of developers, one may need to communicate with securely at some point. Eg, I want to verify the GPG signature on the Tor browser, but I never met anyone on the team, and how do I know who knows the team?
My personal network actually extends very far. I did the FOSDEM key signing party several times, so my theoretical reach is enormous. But it can only be achived by hacking around GPG's trust model. I need to figure out by hand a path between me and Tor, download the keys, and manually tell GPG I trust each key's signature. This isn't convenient, user friendly, not as safe as it could be.
2. GPG is unfortunately stuck in the "Unix Philosophy" era, where you're supposed to just invoke the binary and parse its text output. I believe this crippled GPG's adoption, because it's slow. GPG has to do the whole startup, reading its key databases and so on every single time. Back when GPG support was introduced into KMail many years ago this added a very noticeable delay to viewing any signed message.
And it's sadly still the case. The world badly needs a GPG library, that allows one to skip those startup costs, and to avoid the whole intended model of ~/.gnupg and just let a program do things like interpret in-memory data for any conceivable purpose. This is still badly lacking.
PGP is an unfortunate obsolete technology, which sadly failed to evolve with the times.
I think the main thing that crippled PGP is tooling. What we have available is GnuPG, and GnuPG is horrible for every use case but what it was made for: A command-line interactive application, made for a single person's personal usage.
GnuPG insists on a model where it manages everything: key parsing, a key database, and the entire signing/verification process. There's no proper libgnupg either, what gpgme does is calling gpg, and presenting a library interface.
The problem with this is that GnuPG is very unfriendly towards attempts to build something new from the pieces. It really wants to be a commandline application that deals with a single person's encryption/decryption activities. So if you want to say, run statistics on PGP keys, or write a keyserver, or use it to implement signatures for packages, either you do it the GnuPG way, or you very laboriously trick it into doing what you need, or you write your own crypto code.
Option 1 isn't great if you want anything weird like statistics gathering.
Option 2 is just awkward and messy. Both 1 and 2 quickly run into limits. GPG for instance doesn't like trying to work with a database of a million keys. It has heavy startup costs. It's made for humans, not for any kind of heavy lifting.
Option 3 sucks because OpenPGP is extremely complex, and writing crypto code is very ill advised for most people.
And I think that's kinda what crippled the ecosystem. Doing anything but what gnupg wants to do has extreme startup costs, so few people ever try, and most people do it badly.
Doing what the author did here involves really going out of your way -- in a better world we'd have simple to use tooling to do this work, and PyPI would just do validation and reject bad stuff, but doing so is extremely non-trivial in PGP.
I think GPG is an amazing, well-designed, resilient, widely-adopted, well-tooled, time-tested, mathematically-proven technology and standard.
I think the only thing missing is a tolerable user interface that allows one-click key generation, one-click signing, and zero-click validation and verification.
I think that the biggest oversight in using it today is our attachment to our "main" or "primary" key and trying to hold on to it, keep it safe, and if we use multiple keys, trying to keep it all in the same "tree" or keyring.
We could be using it on every website and platform, and instead of creating an identity on the server, storing our identity locally, either on the filesystem, in LocalStorage, or some other way.
In fact, that's exactly the model I'm using in my web-based forum system. "Registering" an account is just generating a key, and posting something "with my identity" is just signing it with PGP.
In fact, I don't have a single feature which uses encryption yet. Only signing. Encryption is a bit of a red herring with PGP, I think verifiable signing and tooling for almost every platform and language in existence are its two real killer features.
Without nation-state backing, I wouldn't trust it to keep something secure or private. On the other hand, its portability, adaptability, and compatibility is unmatched by any tool that I'm aware of. It allows you to have a portable identity that you can own and secure, and do it all in plaintext.
And the content, identities, votes of my forum can be migrated, cloned, copied, synchronized among any other forum like it, or used outside of it with the most popular identity tooling in existence at your disposal. Just download a zip of text files and you're good to go!
I decided to take this opportunity to retire my PGP keys for good. Over time I’ve come to view PGP as largely a failure — it never reached the critical mass, the tooling has always been problematic, and it’s now a dead end.
PGP is a failure because it has no critical mass, so author writes ~1300 lines of C code that will never reach critical mass, reinventing gpg-zip. Something something irrelevant swipe at email? Something something irrelevant swipe at git?
Author lists a few requirements, saying that PGP satisfies every requirement, and then says "I couldn’t find anything that fit the bill". Bullshit. This is a serious full-blinders-on NIH project.
Don't get me wrong, if you want to have fun writing a thing that does some stuff, and then you want to blog about it, cool. Rock on. Fun times had by all.
But don't be dishonest about it. That's just not right.
The only thing it’s [PGP] been successful at is signing Linux packages
Google "linux encrypt file" and nearly every single hit will be about encrypting files with gpg. Sigh.
> the working hypothesis for privacy enhancing technology was simple: we’d develop really flexible power tools for ourselves, and then teach everyone to be like us... Instead of developing opinionated software with a simple interface, GPG was written to be as powerful and flexible as possible. It’s up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish
I think it's self-explanatory why it's not good that users need to know about SERPENT, IDEA, and TwoFish.
> the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy.
> a ballooning penumbra of OpenPGP specifications and notes so prolific that the entire picture is almost impossible to grasp... Mailpile had to write 1400 lines of python code just to interface with a native GnuPG installation for basic operations, and it still isn’t rock solid.
> journalists who depend on it struggle with it and often mess up (“I send you the private key to communicate privately, right?”)
UX failure leads to user uncertainty or insecure behavior.
What a better replacement looks like (from the comment here):
> Good UX requires thinking about interactions all the way down to the protocol.
> we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy
The problem with GPG is one of key management. The first person who truly solves that well (both reasonably secure and reasonably easy) is going to do well. To date, everybody has failed.
(Disclaimer: I am working on solving that and hope we can make it work. :)
There have been many attempts, usually formed by ignoring the inherent difficulty of creating secure communications while fundamentally being the exact same UX as GPG. It's genuinely incredibly tedious to see there is a new "alternative" and find out once again folks are over-promising and under-delivering.
The “usability nightmare” isn’t PGP/GPG fault, it’s PKI. PKI is hard to use because of its decentralized and free nature.
The “fix” is to channel everything through google, or a government, or some third party that makes it easy and usable, but removes the main benefits of security, transparency, and independence.
I think the reason GPG is all we have and has been for 20+ years is because that’s as good as it gets and better than nothing.
It lets people who know how to use it communicate securely.
So you can document your way out of an impossible to communicate securely nightmare.
I think this perhaps discounts the usefulness of GPG in specific professional applications.
He's judging it on mass adoption; that's fine but it's not the kind of tool that will ever be adopted by most people. It serves a specific purpose (and shoehorning it into email isn't that) and for that purpose I (and other competent professionals) still use and trust it for that purpose.
I am also excited about new tools (like age, which will also never have hundreds of millions of users) along these lines.
I think some similar criticisms could be levied against, say, Adobe Premiere, even though it has an order of magnitude or two more users than PGP (although perhaps not when you consider every apt user in Debian and Debianlikes such as Ubuntu). Industrial software for trained professionals has a lot of sharp corners and footguns. Not all software is (or should be) Instagram.
He's 100% right that GPG email sucks, though. Don't use GPG for email except when attaching secrets.
GPG sadly never grew up. It's a program firmly stuck in the 90s.
The original PGP manual talked about secretly communicating with your lover. That was the usage model, transmitting secret messages to people you could sometimes meet in person, and where the model was you talking to people you directly know.
Try to verify the GPG signature on say, the Tor Browser. It's signed by "Tor Browser Developers (signing key)". Have you ever met this "Tor Browser Developers" person?
Okay, what about the web of trust? Well, GPG offers no help whatsoever in finding a way of making a connection.
And that's why it's dying, because the model it targets ceased to be relevant, and we developed plenty new needs like verifying software signed by random people on the other side of the globe, while GPG did nothing to accommodate that use.
This is true but on the other hand anyone making a serious effort to fix the raging dumpster fire which is PGP usability deserves some kudos. Most people who turn GPG signing on in Git seem to turn it off after hitting one of the many UX failures.
PGP as an ecosystem has always suffered from toolbox-itis: when a tool (especially a cryptographic tool) tries to be everything, it ends up doing nothing particularly well. This got ossified in the form of OpenPGP, and has basically remained the status quo for the last ~25 years.
More generally, the OpenPGP world is in a bit of a double-bind: they can either fix things by breaking compatibility (at which point someone can reasonably observe that there's no good reason not to ditch OpenPGP entirely), or retain compatibility and accept that OpenPGP will never get much better than RFC 4880 and whatever smattering of drafts the GnuPG maintainers agree to implement. One way essentially results in an entirely different tool/standard that happens to be wearing PGP's skin; the other means keeping around misuse-prone and outright broken cryptographic primitives (and bad formats to boot).
(To answer your actual question: email is just a bad substrate for attempting E2EE messaging. Latacora has a great explainer post on why[1]. TOFU is a mostly adjacent concern; trust/identity negotiation is hard, but the thing that makes WhatsApp, Signal, etc. actually work is that they eliminate manual key management and make cryptographic right choices for the user, rather than expecting the user to hold the tool correctly. In other words: they're misuse-resistant, where PGP as an ecosystem has historically not been.)
Is anyone else kinda hoping that GPG/PGP loses enough respect in the tech community that something fresh comes along that really solves a lot of the UX and security issues they have? (Acquiring keys, rotating keys, identifying compromised keys, and most importantly either reaches a large enough percentage of emails sent that usage of it is not in itself an immediate flag to monitor or can be implemented as a side channel not directly including the signature in the email payload itself.)
> The protocol reflects layers of cruft built up over the 20 years that it took for cryptography (and software engineering) to really come of age, and the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy. [0]
> We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol. [1]
GPG doesn't have competitors because modern security thought rejects the approach and treats it as a relic.
The modern thought is that security can't be an add-on, it needs to be part of the system. So encryption for a chat client and encryption for a web browser, and signatures on a binary are all different problems to be solved differently.
This reads like an advertisement. I routinely use GPG, and it is useful for me. It's not perfect (far from perfect, really), but it's a solution for multiple of my problems.
I don't know much about the solution you promote, but as usual with many "PGP killers" it replaces one very specific application of PGP and ignores all the others. Which is ok! Doing one thing and doing it well is the Unix philosophy after all. But it's not something I have use for, and it's not a viable replacement for GPG.
It is largely a success in verifying the identities of the software developers. The entire Debian ecosystem relies on GPG in largely successful ways.
Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication. It appears the PGP just can't be bootstrapped into modernity from a communication point of view. The only major innovation in authentication and identity has been threshold signatures which GPG could support.
reply