Here's a breakdown of the key themes from the Hacker News discussion:
PGP's Design Flaws and Complexity
One of the most prominent themes is a critique of PGP's design, highlighting its inherent complexity and the resulting vulnerabilities. Many believe the format makes it difficult to implement securely.
-
"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." - woodruffw
-
"What you're seeing me and 'woodruffw implying is that modern formats are (deliberately) trivial to parse. OpenPGP is not. That is a security design feature that OpenPGP lacks, and it's a big one, because it's caused multiple issues already." - tptacek
-
"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." - tptacek
-
"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." - cbarrick (who then admits to having been mistaken later in the thread)
Parsing Vulnerabilities and Implementation Issues
A related theme focuses on the specific types of vulnerabilities that arise due to PGP's parsing requirements and complex packet format. The initial post highlights a critical parsing vulnerability, and the discussion delves into the difficulty of correctly implementing PGP due to its design.
-
"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." - woodruffw (referring to the vulnerability described in the linked article)
-
(Referring to the vulnerability) "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." - tptacek
-
OpenPGP.js maintainer Twiss provides some background about the specific issue discussed in this submission and claims it's more interesting than making the same high-level points about OpenPGP. This nuance touches on the message grammar validation being incomplete and that the streaming decryption/validation code affected how the packet sequence was processed. A later optimization caused an inconsistency in which packets were being read when and that the architecture of the code made it possible to return different data than what was verified.
Blame vs Learning: Balancing Fault-Finding with Improvement
Twiss, an OpenPGP.js maintainer, suggests balancing blame and a focus on OpenPGP.js learning how to improve from this flaw.
- "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." - twiss
The Validity of Using Implementation Vulnerabilities When Evaluating a Cryptosystem
tptacek states that when evaluating the design of a cryptosystem, implementation vulnerabilities (at least in mainstream implementations) should be debited to the design.
- "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." - tptacek
PGP's "Clanking" and "Outmoded" Design
Another strong sentiment is that PGP's design is outdated and needs to be replaced with something more modern.
- "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." - tptacek
PGP vs. S/MIME (and other Alternatives)
The comparison of PGP to other secure email standards, particularly S/MIME, is a recurring theme. While S/MIME isn't considered ideal, some argue that PGP is still worse due to its broader scope of flaws.
- "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...All that said, I don't think I would treat S/MIME (or CMS, or PKCS#7) as a guiding star...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." - woodruffw
Limitations of Encrypted Email and Metadata Leakage
A significant portion of the discussion argues that encrypted email, in general, has inherent limitations, primarily due to inevitable metadata leakage (to, from, date). This makes it less effective against sophisticated adversaries.
- "With email, you necessarily leak the triple (to, from, date): no matter how good your cryptosystem is, that information can be pulled from the mailserver logs...if your main threat adversary is state-level actors, you've already lost if you're using email simply because you're using email." - jcranmer
The Pragmatic Reality of Using PGP Despite Its Flaws
Despite acknowledging PGP's problems, some argue that it remains a practical choice due to the lack of viable alternatives for certain use cases, particularly for store-and-forward communications in environments with limited connectivity or situations where other solutions are unusable.
- "Unfortunately, modern cryptographers refuse to design systems for confidentiality of store-and-forward communications...So, until somebody does better, PGP email it is." - mananaysiempre
The "Threat Model" and Appropriateness of Encrypted Email
The discussion includes the idea that the need for or effectiveness of encrypted email is dependent on the specific threat model. In scenarios where state-level adversaries are the primary concern, the unavoidable metadata leakage of email makes it a poor choice.
- "...if messages are important enough that they need to be protected from state-level adversaries, then they're important enough that you shouldn't care about all the other reasons you like SMTP. If any of SMTP's affordances trump message security, you're LARPing the security part: you're protecting them in a threat model that doesn't correspond to a real-world attacker." - tptacek
In conclusion, the Hacker News discussion presents a multi-faceted critique of PGP, acknowledging its design flaws and resulting vulnerabilities, but also recognizing the pragmatic constraints that sometimes lead to its continued use. The discussion highlights the importance of aligning security measures with the specific threat model and considering the limitations of email in high-security scenarios.