Spoofing OpenPGP.js signature verification
31 comments
·June 10, 2025tptacek
mananaysiempre
Unfortunately, modern cryptographers refuse to design systems for confidentiality of store-and-forward communications, motivated by the fact that one can provide better security in instant messaging[1] (which in most cases implies vendor lock-in). Age is one of the few systems that could accomodate email, and its author’s “solution”[2] is for the user do ASCII armor/dearmor like a caveman, which handily loses to PGP/MIME in just about every email client that supports the latter. So, until somebody does better, PGP email it is.
[1] https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
tptacek
They're right about that.
https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
But none of that excuses PGP's clanking and outmoded design. Things that are bad are bad. We can't moralize our way around that.
mananaysiempre
I don’t really want to make a moral argument about PGP. Yes, the design of PGP is bad even if we hold its problem statement fixed. The thing is, the people I would trust to design something better consider that problem not worth solving. So if I as a user do want a solution to that problem[1], I’m stuck with PGP, which is bad. But at least it makes an attempt.
[1] Because I need to be in areas with bad connectivity often enough that I don’t want my every communication method to require a Internet connection to be available continuously (or even daily). Because Signal’s refusal to issue me an account without a phone number (which I cannot legally obtain without tying it to my government ID) is a real risk to my personal safety, given my particular situation. Because Signal’s stance on alternative implementations and the like is a hair’s breadth away from my refusing to use it. Some of these you could call moral arguments, but none of them are about PGP, as such.
jcranmer
I'll admit that my knowledge of signed/encrypted email is mostly from S/MIME (and underlying CMS), so I'm curious if you could enlighten me on what PGP is doing that is so much more insane than that.
woodruffw
Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs.
On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from certificates on the Internet PKI being less of a wild west than PGP certificates, and from having a community group (the S/MIME Cert WG of the CA/B Forum) invested in strengthening S/MIME's certificate profile beyond the baseline stipulated in RFC 5280. Of course, for non-public S/MIME deployments, none of that applies.
All that said, I don't think I would treat S/MIME (or CMS, or PKCS#7) as a guiding star: EFAIL affected S/MIME too[1]. But they have the "advantage" of being bad at just their niche (signing and encryption of email), versus being bad at every niche. The latter is PGP's historic curse.
[1]: https://efail.de/
jcranmer
The way I've previously internalized it is CMS is bad principally because it's generic container of general generalizablity (on multiple levels, even) and the fundamentally wrong notion that signature and encryption are fully orthogonal. But generic generalizability can be ameliorated with a concerted, coordinated effort. As for S/MIME (specifically, working out how to embed CMS in MIME)... well, email and MIME make a good solution impossible from the outset, and S/MIME is probably the least bad you can do.
Encrypted email can never have a good solution simply because email is the poster child for "Why Postel's Law is a bad idea"
tptacek
I'm hanging back hoping 'woodruffw answers this so I don't have to. :)
woodruffw
Another year, another critical parsing vulnerability in the PGP ecosystem. Latacora has an excellent post[1] that touches on the excessive complexity of PGP's encoding which, remarkably, probably isn't even in the top 3 things wrong with PGP.
My personal favorite of these is when someone sent a weaponized compression packet to oss-sec in 2022[2].
[1]: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
upofadown
To save typing, I came up with a commentary on "The PGP Problem":
* https://articles.59.ca/doku.php?id=pgpfan:tpp
The complaint about excessive complexity was about the packet length representation. That isn't a really great example. The PGP packet length representation is fairly straightforward.
woodruffw
You've linked this commentary in just about every PGP thread I've seen on HN, but the vulnerabilities keep coming. I don't think a dynamic TLV encoding was defensible a decade ago, and it certainly isn't defensible in 2025.
(As the Latacora post points out, this is the same essential error that cryptographic applications of BER make. The difference is that serious users of ASN.1 have mostly sobered up and switched to DER; no such sobering has happened in the PGP ecosystem.)
tptacek
You are writing this comment on a story where that packet format literally created a signature bypass vulnerability. Tell us more about how straightforward it is?
cbarrick
The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets.
Edit: foot successfully inserted in mouth
deknos
with that argument TLS would be insecure, because there are insecure TLS implementations.
egberts1
[flagged]
This is not normal. Modern cryptosystems don't have anything like PGP's insane "packet" format, which has caused other problems before this. There's no principal of design that would lead you to what PGP came up with, and the only reason we still have to deal with it is path dependence. I don't even care if you call the next design "PGP2", just throw this system in the bin and start over.