7 ms·
The PGP problem (2019)
- brianjlogan 10mo agoIs anyone else unable to read the report on mobile? Completely broken styling for me.
- nine_k 10mo agoCan't confirm, works fine for me (Android, Firefox).
- shakna 10mo agoProbably resurfacing, because we have some new attacks thanks to CCC. [0] [0] https://news.ycombinator.com/item?id=46453461 https://news.ycombinator.com/item?id=46453461
- shakna 10mo agoWorth noting: minisign and age were also affected by a couple things here. 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.
- stackghost 10mo agoThe mark of good security is not "has no bugs". It's how the maintainers respond to security-relevant bugs.
- tptacek 10mo agoThe minisign bug was much less severe than the (insane) GPG signing bugs, and the age bug wasn't a cryptographic thing at all, just a dumb path sanitization thing. Minisign was not in fact affected by most everything GPG was. The GnuPG team wontfixed one of the most significant bugs!
- croemer 10mo agoIndeed, I saw it linked to in that thread, read it and thought it'd be worth resurfacing.
- jairuhme 10mo agoCan the link be updated to not be to the end of the page?
- croemer 10mo agoYes, that would be nice - when I posted it I forgot to clean the URL. I'm sorry! I've sent an email to moderators to request the change. Update: URL has been updated
- felipelalli 10mo agoEven though I read so many posts criticizing PGP, it's still difficult for me to find an alternative. He states in the article that being a "Swiss Army Knife" is bad. I understand the argument, but this is precisely what makes GPG so powerful. The scheme of public keys, private keys, revoke, embedded WOT, files, texts, everything. They urgently need to make a "modern version" of GPG. He needs a replacement, otherwise he'll just be whining.
- schoen 10mo agoThere's a section in this post with proposed replacements: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#the-answers 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.)
- eddythompson80 10mo agoI’m still frustrated by the criticism because I internalized it a couple of years ago and tried to move to age+minisig because those are the only 2 scenarios I personally care about. The overall experience was annoying given that the problems with pgp/gpg are esoteric and abstract that unless I’m personally are worried about a targeted attack against me, they are fine-ish. 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.
- aniviacat 10mo ago> the fact that this post is recommending Tarsnap and magicwormhole shows how badly it has aged in 6 years What's wrong with magic wormhole?
- maqp 10mo agoThe biggest issue with PGP/gpg is the difficulty of getting rid of it. If you work on big distros, or know someone who works on big distros, please (start asking them to) add https://github.com/jedisct1/minisign https://github.com/jedisct1/minisign to pre-installed packages to facilitate transition. It's almost a chicken egg problem but the sad thing is, no project wants to swap the signing tool to a better one until everyone can verify the new signatures.
- singpolyma3 10mo agoNote that minisign was also vulnerable in the gpg.fail exposures
- Avamander 10mo agoFor starters I'd like to see ssh-agent not being replaced with gpg-agent. Those who need it should install it themselves.
- bgwalter 10mo agoHow does this help people who are not following this issue regularly? gpg protected Snowden, and this article promotes tools by one of the cryptographers who promoted non-hybrid encryption: https://blog.cr.yp.to/20251004-weakened.html#agreement 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.
- tptacek 10mo agoYou could also say Cryptocat protected Snowden; he used it to communicate with reporters. So, that's how well that argument holds up.
- bgwalter 10mo agohttps://en.wikipedia.org/wiki/Cryptocat#Reception_and_usage https://en.wikipedia.org/wiki/Cryptocat#Reception_and_usage "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.
- nine_k 10mo agoI agree that age + minisign comprise a much neater stack that does basically everything I would need to use PGP for. 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.
- nine_k 10mo agoBTW apparently age has plugins that allow to use FIDO2 and TPM for cryptography.
- some_furry 10mo ago> Neither of them supports hardware keys though, as much as I could see. https://github.com/str4d/age-plugin-yubikey https://github.com/str4d/age-plugin-yubikey
- matted7505 10mo agoAfter reading the PyCon 2016 presentation about wormhole, and say my understanding of channels is correct (that is, each session on the same wireless network constitutes a session). What's stopping a hostile 3rd party, who wishes to stop a file transfer from happening, from spamming every channel with random codes?
- stackghost 10mo agoAnyone know why GitHub doesn't support signing commits with signify/minisign?
- some_furry 10mo agoMy first guess is, "Not enough people have asked for it." So let's get the party started: https://github.com/orgs/community/discussions/183391 https://github.com/orgs/community/discussions/183391
- Arrowmaster 10mo agoGitHub is not git and does not control what features get added to git. It looks like there are some wrapper scripts to make git sign commits with other tools using the GPG cli interface but nothing official.
- bgwalter 10mo ago[flagged]
- some_furry 10mo ago> 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-used-by-signal/ 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.
- bgwalter 10mo agoOf course you omit the QR code issue in your response, just like tptacek tried to deflect in the other subthread after his Cryptocat objection was refuted.
- some_furry 10mo ago> Of course you omit the QR code issue in your response, 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.
- bgwalter 10mo agoI no longer respond if you use Simple Sabotage Field Manual tactics. EDIT: The submission was flagged from the front page seconds after this reference.
- upofadown 10mo agoMy comments on The PGP Problem: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- anta40 10mo agoI'm curious. What's the advantage of using signify/minisign instead of good old PGP/GPG?
- some_furry 10mo agoPGP/GPG is a complicated mess designed in the 1990's and only incrementally updated to add more complexity and cover more use-cases, most of which you'll never need. Part of PGP/GPG is supporting a large swath of algorithms (from DSA to RSA to ECDSA to EdDSA to whatever post-quantum abomination they'll cook up next). 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 https://github.com/soatok/minisign-php Complexity is the enemy of security.
- deleted 10mo ago[deleted]
- deknos 10mo agoi like the approach by the bsd people. shut the f* up and code. 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.
- NooneAtAll3 10mo ago> If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. > 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
- tialaramex 10mo ago[flagged]
- bayesnet 10mo agoI wasn’t aware of the efail disclosure timeline. Apparently Koch responds to the report by noting that GPG prints an error when MDC is stripped, which has eerie parallels to the justification behind the recent gpg.fail WONTFIX response (see https://news.ycombinator.com/item?id=46403200 https://news.ycombinator.com/item?id=46403200)
- upofadown 10mo agoI think the two cases are different. The EFAIL researchers were suggesting that the PGP code (whatever implementation) should throw an error on an MDC integrity error and then stop. The idea was that this would be a fix for EFAIL in that the modified message would not be passed on to the rest of the system and thus was failsafe. The rest of the system could not pass the modified message along to the HTML interpreter. 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 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.
- tptacek 10mo agoThe PGP could obviously should throw an error on any MDC integrity failure!
- xelxebar 10mo agoRecently, this opinionated list of PGP alternatives went around: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ 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.
- DJBunnies 10mo agoTall order.
- some_furry 10mo agoOne of the projects I alluded to in that post makes a technological solution to what you want easy to build, but the harder problem to solve is societal (i.e., getting it adopted). https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#auxiliary-data 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]); } And then you can send the encrypted file in an email without a meaningful subject line and you'll have met your stated requirements. (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/ https://words.filippo.io/keyserver-tlog/
- zimmerfrei 10mo agoAs 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 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). [0] https://sequoia-pgp.org/ https://sequoia-pgp.org/ [1] https://archive.fosdem.org/2025/events/attachments/fosdem-2025-6297-a-practical-introduction-to-using-sq-sequoia-pgp-s-cli/slides/237970/presentat_pvYEqR5.pdf https://archive.fosdem.org/2025/events/attachments/fosdem-20...
- SahAssar 10mo agoBut if you use the modern crypto stuff you loose interoperability, right? What is the point of keeping the cruft of the format if you still won't have compatability if you use the modern crypto? The article mentions this: > 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.
- zimmerfrei 10mo agoWhen you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not). 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".
- deknos 10mo agoon another note: it's so funny that this says, that email should not be used, when the whole world uses email. it's so far detached from reality...
- anthk 10mo agoGPG, 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 being overfeatured. LibreSSL did the same over OpenSSL.
- ekjhgkejhgk 10mo agoI 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 fucking awesome. What am I missing?
- orblivion 10mo agoThe 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 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 might expect ivory tower types to dismiss UX issues).
- ekjhgkejhgk 10mo agoI 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.
- Arrowmaster 10mo agoMy impression is that GPG when used correctly is secure. But there are so many problems with it that the chances of shooting yourself with one of the footguns is too high for it to be a reliable solution. 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.
- defanor 10mo agoThis OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availability issues. Almost nothing of that is available from Linux distributions' system repositories. Integration with other software and infrastructures is lacking. Dealing with multiple specialized tools is more of a headache even for expert users, especially when their added benefits do not make much sense given one's threat model. OpenPGP/GnuPG is more resilient and versatile than those, still usable where those are not. 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.
- woodruffw 10mo agoOne of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter. (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.
- api 10mo agoPGP is horrible and way overly complicated but this article concludes by trading that for a long list of piecemeal solutions, some of which are cloud based and semi or fully proprietary. 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?
- pheggs 10mo agoI 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.
- tptacek 10mo agoIt'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.
- mjevans 10mo agoYes, 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.
- pheggs 10mo agowell that's fair, but sounds more like a email client issue than an actual issue with gpg/pgp. My client shows pretty clearly when it gets encrypted. But maybe I am oblivious.
- tptacek 10mo agoI agree that it's an email problem, which is why I wrote a whole article about why email can't be made secure with any reasonable client. But email is overwhelmingly the messaging channel PGP users use; in fact, it's a common-cited reason why people continue to use PGP (because it allows them to encrypt email).