The PGP problem (2019)
latacora.com
latacora.com
I think such an article would seem more convincing, at least to me, if more sensible alternatives were proposed. Ideally without the advice to not encrypt email, without assumptions of continued availability of all the online services, of trust to certain third parties, and so on. Or it could be just a plain criticism without suggestions, which would still be somewhat informative.
Edit: there is another list of alternatives in a sibling comment, advising against (well, actually being quite hostile towards, and generally impolite) usage of what I had in mind as one of the possible more sensible alternatives: XMPP with OMEMO. Though upon skimming the criticism of that, I have not found it particularly convincing, either, and it just looks like some authors try to be particularly provocative/edgy.
(Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)
But even this jumps ahead, given that the alternatives are not in fact proprietary. The list of open source tool alternatives has been the same for close to a decade now:
* For messaging/secure communication, use Signal. It’s open source.
* For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.
* For signing, use minisign, or Sigstore, or even ssh signing. All are open source.
It matters - because Satan can disconnect the centralized nodes.
Yes, but security usually includes availability, and I mentioned a setting with service blocking above. Like that by a government.
> (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)
How is it a red herring?
> For messaging/secure communication, use Signal. It’s open source.
From my point of view, it is complicated by Signal being blocked here (and it being centralized helped to establish such blocking easily), likely the phone number verification won't work here, it is not available without a phone, and it is not available from F-Droid repositories on top of that. Currently money transfers are also complicated, so finding some foreign service that would help to circumvent phone number verification is also complicated, and not something I would normally do even without that. All this Internet blocking is a new development here, but such availability issues due to centralization were anticipated for a long time, and are a major motivation behind federated or distributed systems. Some mail servers are also being blocked, but generally mail still works, and less of a pain to use.
> For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.
> For signing, use minisign, or Sigstore, or even ssh signing. All are open source.
These I find to be okay. Having to install them in addition to GnuPG that is usually already available, but that is to be expected; they are available at least from Debian repositories, so not something to complain about when considering alternatives. Likewise with the key sharing: not getting to reuse OpenPGP's PKI, and will have to replace that somehow, but it is not like it is used widely and consistently anyway, so perhaps not much of a loss in practice. Likewise with familiarity of the users: I would expect a little more friction with such tools, compared to GnuPG, but not much more. And I don't see actual usage downsides apart from those. Though the benefits also seem a bit uncertain, but generally that sounds like a switch that makes sense to consider.
Hey, I take issue with that. keys.openpgp.org is just about the only thing running smoothly in the openpgp ecosystem :P
Probably because of my limited usage of Sequoia, but it seemed compatible enough with GnuPG (when it comes to OpenPGP, that is; not their CLIs or APIs): not completely, but enough in practice. The cryptography also looks modern enough to me: it is not like even GnuPG defaults to compatibility with particularly old systems.
If they were notably incompatible though, I guess I would prefer GnuPG for the availability and compatibility reasons, as mentioned above, mainly to avoid fragmentation. Though if there was a better system, as versatile, preferably as easily available, even if not as widely used, I would consider that as well.
Apparently the threat models we have in mind, along with the settings to use those tools in, differ: as mentioned in the sibling comments, my concerns (or past concerns, current issues to deal with) are more about availability, confidentiality in the face of mass surveillance and over varied channels (i.e., versatility). I see (and hear of) people neglecting cryptography altogether in cases where cryptography would be beneficial (for confidentiality, most often), the local government and other threat actors focusing on heavy-handed and basic attacks (aiming to disrupt use of cryptography, such as by blocking the IMs they do not control and other online services, or--perhaps even more often--making use of it not being used at all in the first place); so I struggle to see how, say, age + minisign would have helped anyone over GnuPG in such conditions, or even those rare few who are targeted individually. But I find it much easier to see how a wider adoption of any sufficiently good, versatile, available, and standardized/compatible tools would be useful. So that people would be able to communicate securely using those, as well as the same person would be able to easily decrypt a file they had encrypted years ago without keeping around a toolbox of varied--and likely partially abandoned--tools, which, taken together, would likely be a worse legacy pile of software and algorithms than OpenPGP and its implementations, moving the specification with its different legacy options into users' heads (and replacing the implementation with their manual operations).
Of course everyone having and properly using a set of most polished and foolproof tools implementing algorithms considered most secure (out of practical ones) at the time would be good, but there are issues with adoption, software acquisition and updates, interference (i.e., adverse conditions, including blocking), key distribution, as well as the moving target (changing recommendations/views) to take into account. The algorithms, implementations, and UIs are not to be ignored, but neither are they everything there is, so one has to prioritize all the components.
https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...
I was also frustrated with this criticism in the past, but there are definitely some concrete alternatives provided for many use cases there. (But not just with one tool.)
If someone scotch tapes age+minisig and convince git/GitHub/gitlab/codeberge to support it, I’ll be so game it’ll hurt. My biggest usage of pgp is asking people doing bug reports to send me logs and giving them my pgp keys if they are worried and don’t want to publicly post their log file. 99.9% of people don’t care, but I understand the 0.1% who do. The other use is to sign my commits and to encrypt my backups.
Ps: the fact that this post is recommending Tarsnap and magicwormhole shows how badly it has aged in 6 years IMO.
What's wrong with magic wormhole?
There are two parts of "sending encrypted files": the encryption and the sending. An offline tool (e.g. PGP or age) seems only necessary when you want to decouple the two. After all, you can't do the sending with an offline tool (except insofar as you can queue up a message while offline, such as with traditional mail clients).
The question thereby becomes "Why decouple the sending from encryption?"
As far as I can see, the main (only?) reason is if the communication channel used for sending doesn't align with your threat model. For instance, maybe there are multiple parties at the other end of the channel, but you only trust one of them. Then you'd need to do something like encrypt the message with that person's key.
But in the use-case you mentioned (not wanting to publicly post a log file), I don't see why that reason would hold; surely the people who would send you logs can trust trust Signal every bit as easily as PGP. Share your Signal username over your existing channel (the mailing list), thereby allowing these people to effectively "upgrade" their channel with you.
for some people, that's important
Is this about commit signing? Git and all of the mentioned forges (by uploading the public key in the settings) support SSH keys for that afaik.
git configuration:
gpg.format = ssh
user.signingkey = /path/to/key.pub
If you need local verification of commit signatures you need gpg.ssh.allowedSignersFile too to list the known keys (including yours). ssh-add can remember credentials. Security keys are supported too.
>They urgently need to make a "modern version" of GPG.
Absolutely not.
Ignoring your comment’s lack of constructive criticism, I’m going to post this meaningful implementation that an excellent cryptographer, Soatok Dreamseeker, is working on: [1].
You may also search for his posts in this HN thread, his nickname is “some_furry”.
[1]: https://github.com/fedi-e2ee/public-key-directory-specificat...
If people want to build WoT on top of ny design, I won't stop them, but it's not a goal of mine.
That can't happen in any modern encrypted messenger. It does happen routinely with encrypted email.
pgp as a tool could integrate with that, but in practice fails for... many reasons, the above included. All the other key exchange / etc issues as well.
Even if secure email clients exist that always make right choices, because you can’t know what client all your recipients are using, all it takes is one person with a “bad” client (which, keep in mind, is a client that accurately implements the protocol but doesn’t enforce additional security rules on top) to ruin things.
https://cloud.google.com/blog/topics/threat-intelligence/rus...
Some Ukrainians may regret that the followed the Signal marketing. I have never heard of a real world exploit that has actually been used like that against gpg.
Yet one system is declared secure (Signal), the other is declared insecure. Despite the fact that the QR code issue happened in a war zone, whereas I have not heard of a similar PGP fail in the real world.
"Because linking an additional device typically requires scanning a quick-response (QR) code, threat actors have resorted to crafting malicious QR codes that, when scanned, will link a victim's account to an actor-controlled Signal instance."
This is a complete failure of the cryptosystem, worse than the issue of responding in plaintext. You can at least design an email client that simply refuses to send plaintext messages because PGP is modular.
I recommend people to spend some time and try out sequoia (sq) [0][1], which is a sane, clean room re-implementation of OpenPGP in Rust. For crypto, it uses the backend you prefer (including openssl, no more ligcrypt!) and it isn't just a CLI application but also as a library you can invoke from many other languages.
It does signing and/or encryption, for modern crypto including AEAD, Argon2, PQC.
Sure, it still implements OpenPGP/RFC 9580 (which is not the ideal format most people would define from scratch today) but it throws away the dirty water (SHA1, old cruft) while keeping the baby (interoperability, the fine bits).
[1] https://archive.fosdem.org/2025/events/attachments/fosdem-20...
> Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which is not great.
Other implementations also don't support stuff like Argon2.
So it feels like the article is on point when it says
> You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both.
sequoia's defaults are reasonable as far as I remember. It's also bit strange that the post found it defaulted to using AEAD in 2019 when AEAD was standardized only in 2024 with RFC 9580.
But the elephant in the room is that gpg famously decided to NOT adopt RFC 9580 (which Sequoia and Proton do support) and stick to a variant of the older RFC (LibrePGP), officially because the changes to the crypto were seen as too "ground-breaking".
Over the decades, PGP has already transitioned out of old key formats or old crypto. None of us is expecting to receive messages encrypted with BassOmatic (the original encryption algorithm by Zimmermann) I assume? The process has been slow, arguably way slower than it should have after the advancements in attacks in the past 15 years (and that is exactly the crux behind the schism librepgp/opengpgp). Nonetheless, here we are, pointing at the current gpg as "the" interoperable (yet flawed) standard.
In this age, when implementations are expected (sometimes by law) to be ready to update more quickly, the introduction of new crypto can take into account adoption rates and the specific context one operates in. And still, that happens within the boundaries of a reasonably interoperable protocol.
TLS 1.3 is a case in point - from certain points of view, it has been a total revolution and break with the past. But from many others, it is still remarkably similar to the previous TLS as before, lots of concepts are reused, and it can be deemed as an iteration of the same standard. Nobody is questioning its level of interoperability, and nobody is shocked by the fact that older clients can't connect to a TLS 1.3-only server.
But stipulate that it does, and riddle me this: what's the point? You can use Sequoia set up for "modern crypto including AEAD", yes, but now you're not compatible with the rest of the installed base of PGP.
If you're going to surrender compatibility, why on Earth would you continue to use OpenPGP, a design mired in 1990s decisions that no cryptography engineer on the planet endorses?
If your audience is wider, dont use AEAD but make sure to sign the data too.
With respect to the 90's design, yes, it is not pretty and it could be simpler. It is also not broken and not too difficult to understand.
Neither of them supports hardware keys though, as much as I could see. OTOH ssh and GnuPG do support hardware keys, like smart cards or Yubikey-like devices. I suppose by the same token (not a pun, sadly) they don't support various software keychains provided by OSes, since they don't support any external PKCS11 providers (the way ssh does).
This may reduce the attack needed to steal a private key to a simple unprivileged infiltration, e.g. via code run during installation of a compromised npm package, or similar.
GnuPG has decided a couple things are out of scope, fixed a couple others. Not all is in distro packages yet.
age didn't have the clearest way to report things - discord is apparently the point of contact. Which will probably improve soon.
minisign was affected by most everything GnuPG was, but had a faster turnaround to patching.
Go runs on far more platforms than Discord. And, worse, Discord it's propietary.
https://blog.cr.yp.to/20251004-weakened.html#agreement
So what to do? PGP by the way never claimed to prevent traffic analysis, mixmaster was the layer that somehow got dropped, unlike Tor.
"In June 2013, Cryptocat was used by journalist Glenn Greenwald while in Hong Kong to meet NSA whistleblower Edward Snowden for the first time, after other encryption software failed to work."
So it was used when Snowden was already on the run, other software failed and the communication did not have to be confidential for the long term.
It would also be an indictment of messaging services as opposed to gpg. gpg has the advantage that there is no money in it, so there are unlikely to be industry or deep state shills.
Signal was made by people who then used it to push their get-rich-quick cryptocurrency scheme on users and who threw all their promises of being open-source and reproducible over board for it. The Signal people are absolutely not trustworthy for reasons of money and greed.
I reviewed Signal's cryptography last year over a long weekend: https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...
There's a lot to be said for the utility of reverse engineering tools and skills, but I did not need them, because it was open source. Because Signal's client software still is open source.
Whatever you think about MobileCoin, it doesn't actually intersect with the message encryption features at all. At all.
The only part in Signal that's not entirely open source are the anti-spam features baked into the Signal Server software.
And, frankly, the security of end-to-end encryption messaging apps has so little to do with whatever the server software is doing that it's frankly silly to consider that relevant to these discussions. https://soatok.blog/2025/07/09/jurisdiction-is-nearly-irrele...
And, yes, this is only a server-side feature. See spam-filter (a git submodule) in https://github.com/signalapp/Signal-Server but absent from https://github.com/signalapp/Signal-Android or https://github.com/signalapp/Signal-iOS
> The Signal people are absolutely not trustworthy for reasons of money and greed.
I don't think you've raised sufficient justification for this point.
Only when you can trust that the published client source code is equivalent to the distributed client binaries. The only way to do this is reproducible builds, since building your own client is frowned upon and sometimes actively prevented by the signal people. Signal has always been a my-way-or-the-highway centralized cathedral, no alternate implementations, no federation, nothing. Which was always a suspicious thing. Also, "the signal client is open source software" only holds if you don't count in the proprietary Google blobs that the signal binary does contain: FCM and Maps. Those live in the same process and can do whatever to E2EE...
About the signal client that does the E2EE, reproducible builds are frequently broken for the signal client, e.g.: https://github.com/signalapp/Signal-Android/issues/11352 https://github.com/signalapp/Signal-Android/issues/13565 and many more. Just search their issue tracker. The latter one was open for 2 years, so reproducible builds were broken at least during 2024 and most of 2025 for the client. They don't keep their promise and don't prioritize fixing those issues, because they just don't care. People do trust them blindly and the Signal people rely on that blind trust. Case in point: you yourself reviewed their code and probably didn't notice that it wasn't the code for the binary they were distributing at the time.
Now you might say that reproducible builds in the client you reviewed weren't affected by their Mobilecoin cash grab, and you are right, but it shows a pattern in that they don't care, and even lots of professionals singing their praises don't care.
And their server code does affect your privacy even with E2EE. The server can still maliciously correlate who talks to whom. You have to trust their published source code correctly doing its obfuscation of that, otherwise you get metadata leaks the same as in all other messengers. The server can also easily impersonate you, read all your contacts and send them to evil people. "But Signal protects against this", you say? Well, it does by some SGX magic and the assurance that the code inside the enclave does the right thing. But they clearly don't care about putting their code where their mouth is, they rather put their code where the money was. Behind closed doors, until they could finish their Mobilecoin thingy.
>> The Signal people are absolutely not trustworthy for reasons of money and greed.
> I don't think you've raised sufficient justification for this point.
Trust is hard to earn and easy to squander. They squandered my trust and did nothing to earn it back. Their behavior clearly shows they don't care about trust, because they frequently break their reproducibility and are slow to fix it. They cared more about their coin thing. They are given trust, even by professionals who should know better, because their cryptography is cool. But cryptography isn't everything, and one should not trust them, because they obviously are more interested in Mobilecoin than in trust. What more is there to justify, it's obvious imho.
Yes, fine, they squandered your trust.
You don't speak for all of us.
In the gpg.fail case the researchers suggested that GPG should, instead of returning the actual message structure error (a compression error in their case), return an MDC integrity error instead. I am not entirely clear why they thought this would help. I am also not sure if they intended all message structure errors to be remapped in this way or just the single error. A message structure error means that all bets are off so they are in a sense more serious than a MDC integrity error. So the suggestion here seems to be to downgrade the seriousness of the error. Again, not sure how that would help.
In both cases the researchers entirely ignored regular PGP authentication. You know, the thing that specifically is intended to address these sorts of things. The MDC was added as an afterthought to support anonymous messages. I have come to suspect that people are actually thinking of things in terms of how more popular systems like TLS work. So I recently wrote an article based on that idea:
* https://articles.59.ca/doku.php?id=pgpfan:pgpauth
It's occurred to me that it is possible that the GnuPG people are being unfairly criticized because of their greater understanding of how PGP actually works. They have been doing this stuff forever. Presumably they are quite aware of the tradeoffs.
So let's get the party started: https://github.com/orgs/community/discussions/183391
It looks like there are some wrapper scripts to make git sign commits with other tools using the GPG cli interface but nothing official.
PGP has hung on for a long time because it “works” and is a standard. The same can be said for Unix, which is not actually a great OS. A modern green field OS designed by experienced people with an eye to simplicity and consistency would almost certainly be better. But who’s going to use it?
OpenBSD has signifiy, which works fine. But I wouldn't mind something like a cleaned up age(1) but without the mentioned issues.
GNU tends to stack features like crazy. It had sense over the limited Unix tools in the 90's, but nowadays 'ls -F', oksh with completion and the like make them decent enough while respecting your freedom and not being overfeatured.
LibreSSL did the same over OpenSSL.
Signify/Minisign is Ed25519. Boring, simple, fit-for-purpose.
You can write an implementation of Minisign in most languages with little effort. I did in PHP years ago. https://github.com/soatok/minisign-php
Complexity is the enemy of security.
https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
One use case I've not seen covered is sending blobs asynchronously with forward secrecy. Wormhole requires synchronously communicating the password somehow, and Signal requires reasonable buy-in by the recipient.
Basically, I'd like to just email sensitive banking and customer data in an encrypted attachment without needing to trust that the recipient will never accidentally leak their encryption key.
https://github.com/fedi-e2ee/public-key-directory-specificat...
My current project aims to bring Key Transparency to the Fediverse for building E2EE on ActivityPub so you can have DMs that are private even against instance moderators.
One of the things I added to this design was the idea of "Auxiliary Data" which would be included in the transparency log. Each AuxData has a type identifier (e.g. "ssh-v2", "age-v1", "minisign-v0", but on the client-side, you can have friendly aliases like just "ssh" or "age"). The type identifier tells the server (and other clients) which "extension" to use to validate that the data is valid. (This is to minimize the risk of abuse.)
As this project matures, it will be increasingly easy to do this:
// @var pkdClient -- A thin client-side library that queries the Public Key Directory
// @var age -- An implementation of age
async function forwardSecureEncrypt(file, identity) {
const agePKs = await pkdClient.FetchAuxData(identity, "age");
if (agePKs.length === 0) {
throw new Error("No age public keys found");
}
return age.Encrypt(file, agePKs[0]);
}
(The degree of "forward secure" here depends on how often your recipient adds a new age key and revokes their old one. Revocation is also published through the transparency log.)
However, email encryption is such a mess that most people don't quite appreciate, so I'm blogging about that right now. :)
Also, Filippo just created a transparency-based keyserver for age, fwiw: https://words.filippo.io/keyserver-tlog/
as long as there's not (audited and verified) replacements for each niche, we still have to use it.
sadly even gpg (because of all this fud'ing around) even falls now the grace and tries to say "well, not THAT application, only THAT".. sigh.
Update: URL has been updated
If there's one thing we learned from the Snowden leaks is that the NSA can't break GPG.
Look at it from the POV of someone who like me isn't an expert: on the one hand I have ivory tower researchers telling me that GPG is "bad". On the other hand I have fact that the most advanced intelligence in the world can't break it. My personal conclusion is that GPG is actually fucking awesome.
What am I missing?
The alternatives support newer encryption methods but nothing has fundamentally changed that doesn't make them less secure, but they have less footguns to worry about.
The weakest link in cryptography is always people.
> Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed.
Have a sentence praising Signal followed by a sentence explaining the main critique of Signal (requiring mobile number) makes me question the whole post for credibility