The Pgp Problem (2019)
Key topics
The PGP problem is back in the spotlight, with recent revelations from the CCC exposing new vulnerabilities and reigniting debates about the venerable encryption tool's security and maintainability. Commenters weighed in on GnuPG's response to these bugs, with some praising the maintainers' handling of security-relevant issues, while others pointed out that the project's complexity and "Swiss Army Knife" approach are part of the problem. Alternatives like minisign and age were discussed, although some noted that they had their own issues, and a helpful commenter pointed out that the original article actually proposes replacements. As the discussion unfolded, it became clear that finding a suitable alternative to PGP remains a challenge, making this thread a timely and relevant conversation.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
42
132-144h
Avg / period
12.8
Based on 64 loaded comments
Key moments
- 01Story posted
Dec 28, 2025 at 3:39 AM EST
8 days ago
Step 01 - 02First comment
Jan 2, 2026 at 8:07 PM EST
6d after posting
Step 02 - 03Peak activity
42 comments in 132-144h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 4, 2026 at 6:48 PM EST
6h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
[0] https://news.ycombinator.com/item?id=46453461
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://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.
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.
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.
"Use Signal. Or Wire, or WhatsApp, or some other Signal-protocol-based secure messenger."
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.
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.
https://github.com/str4d/age-plugin-yubikey
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.
https://cloud.google.com/blog/topics/threat-intelligence/rus...
Of course, people here who have recommended Signal are silent about these issues and rather continue to bash gpg.
I've reviewed Signal extensively on my blog. https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...
I analyze cryptosystems based on what an attacker can do, given sufficient capabilities.
"The user adds the wrong person to a group chat" is not a cryptographic weakness, nor a particularly interesting one. Why would I have anything to say about it?
We aren't "silent" about your pet peeves. We just have lives and more interesting things to talk about.
> EDIT: tptacek enters the chat, my messages are downvoted. This is how he convinces people to use Signal.
This kind of comment gets people banned from Hacker News. Please stop that.
What? You mean a vulnerability that was mitigated in February of last year? In what sense am I obligated to comment on such a thing? You use the verb "omit" as if such an obligation exists. This is delusional rhetoric.
First you complain about tptacek choosing to comment about a tangent, and then you get upset that I didn't entertain your tangent. Pick a lane.
> just like tptacek tried to deflect in the other subthread after his Cryptocat objection was refuted.
I didn't see a refutation.
You just did.
> if you use Simple Sabotage Field Manual tactics.
No idea what you're even talking about there.
* https://articles.59.ca/doku.php?id=em:sg
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://articles.59.ca/doku.php?id=pgpfan:tpp