[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

[tptacek]

I wrote the "PGP Problem" article and definitely was not just talking about "the format of individual packets", which you might be able to tell from the fact that it brings up a quadratic parsing DoS in that design as well.

[upofadown]

Since you are the author of TPP could you please explain how your example shows some sort of quadratic parsing DOS? I don't see anything like that. Just a huge number of signatures.

[tptacek]

The postmortem on that DoS attack was at pains to point out that they were "officially" documenting only one of the vulnerabilities. Somewhere on an old drive I have the giant mountain of mailing list posts I sorted through to write that post, and I may dig it out at some point, but right now you're just going to have to take my word for the fact that I was not suggesting that the only problem with the packet format was the fact that you can represent lengths 8 different ways.

This is a deeply silly discussion to be having on this particular thread, which, again, is about a vulnerability that owes to the PGP packet format.

[woodruffw]

An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

[twiss]

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes...

The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").

Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853

[tptacek]

When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

[twiss]

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false.

Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:

- The message grammar validation was incomplete, as mentioned

- The streaming decryption/validation code affected how the packet sequence was processed

- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when

- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)

All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.

[deknos]

with that argument TLS would be insecure, because there are insecure TLS implementations.

[pvg]

That's not the argument, it's that it's a bad design repeatedly shown to be shown to be prone to serious vulnerabilities and it's silly to argue it's not a bad design at yet another such time.

People have made serious arguments for all sorts of design problems in SSL/TLS.

[deknos]

the design is not bad per se. pgp is just a bit outdated and needs an overhaul.

And cryptographic serialization is just difficult.

[pvg]

It's not resting, it's dead.