Live data from Hacker News

The PGP problem (2019)

latacora.com

91–100 of 121 posts

Re: The PGP problem (2019)

#91
post #82

I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.

It's not that someone can forward your mail unencrypted. It's that in the normal operation of the system, someone taking the natural next step in a conversation (replying) can --- and, in the experience of everyone I've talked to who has used PGP in anger for any extended period of time, inevitably does --- destroy the security of the entire conversation by accidentally replying in plaintext.

That can't happen in any modern encrypted messenger. It does happen routinely with encrypted email.

Re: The PGP problem (2019)

#92

As mentioned a few days ago, this post mainly covers a gpg problem not a PGP problem. 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…

I wrote the post and object to the argument that it primarily covers GnuPG issues.

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?

Re: The PGP problem (2019)

#93

Earlier quoted context omitted.

I think GP’s point isn’t that you don’t have the freedom to decide your own interoperability (you clearly do), but that the primary remaining benefit of PGP as an ecosystem is that interoperability. If you’re throwing that away, then there’s very little reason to shackle yourself to a larger design that the cryptographic community (more or less) unanimously agrees is dangerous and antiquated.

It is not a coincidence that most of the various proposed alternatives to PGP (signal, wormhole, age, minisign, etc) are led by a single golden implementation and neither support nor promote community-driven specifications (e.g., at the IETF). 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 encrypt…

You're right, it's not a coincidence. The track record of standards-body-driven cryptography is wretched. It's why we all use WireGuard and not IPSEC. TLS 1.3 is an actually good protocol, but it took for-ev-er to get there, and part of that process involved basically letting the cryptographers seize the microphones and make decisions by fiat in the 1.2->1.3 shift (TLS 1.3 also follows a professionalization at CFRG). It's the exception that proves the rule. It's contemporaneous sibling is WPA3 and Dragonfly, and look how that went.

Re: The PGP problem (2019)

#94
post #64

GPG, as OpenSSL, are too huge and complex in order to use them on daily basis. 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…

Which "mentioned issues"?

Re: The PGP problem (2019)

#95
post #91
post #82

I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.

It's not that someone can forward your mail unencrypted. It's that in the normal operation of the system, someone taking the natural next step in a conversation (replying) can --- and, in the experience of everyone I've talked to who has used PGP in anger for any extended period of time, inevitably does --- destroy the security of the entire conversation by accidentally replying in plaintext. That can't happen in any…

Yes, it's a problem with _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.

Re: The PGP problem (2019)

#96

Earlier quoted context omitted.

No money in anything? 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.

> 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. 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 n…

> Because Signal's client software still is open source.

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.

Re: The PGP problem (2019)

#97
post #82

I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.

Yes, it is odd that this criticism is only allowed for gpg while worse Signal issues are not publicized here:

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.

Re: The PGP problem (2019)

#98

Earlier quoted context omitted.

> 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. 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 n…

> Because Signal's client software still is open source. 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, n…

> They squandered my trust

Yes, fine, they squandered your trust.

You don't speak for all of us.

Re: The PGP problem (2019)

#99

I feel like I'm taking pills, but hear me out. 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 fu…

The NSA can't break GPG assuming everything is working properly. This blog post (which to be fair I only skimmed) explains that GPG is a mess which could lead to things not working properly, and also gives real life examples. You may also want to see https://gpg.fail (you can tell they're from the ivory tower by the cat ears). The blog post also mentions bad UX, which you and I can directly appreciate (if anything I…

I am well familiar with that presentation at CCC. Yes, the presentation are by people who live in the low stakes world of theoreticals as you can tell by the cat ears.

Re: The PGP problem (2019)

#100
post #45

Earlier quoted context omitted.

> The so-called web of trust is meaningless security theatre. 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...

Keyservers already “solved” this problem without needing federation because we only needed one keyserver anyway. Federating them isn’t going to do anything. Web of trust is a broken system that sounds super cool until you try to really use it. It has so many flaws that there’s really no way to revive it. Keybase tried to do something about it and also failed.

Keybase was doing great until it got acquired by Zoom and people felt uneasy about the implications, IIRC
Post reply on HN