The PGP problem (2019)

Original Article ↗ Hacker News Discussion ↗

PGP/GnuPG’s aging design, complexity, and foot‑gun‑prone UX are criticized as making secure email and software signing fragile in practice, even if the underlying cryptography is sound when correctly used. Commenters weigh the tradeoffs of replacing it with simpler, purpose‑built tools like age and minisign, newer OpenPGP implementations such as Sequoia, or end‑to‑end messengers like Signal—raising concerns over interoperability, centralization, hardware key support, and real‑world threat models. Many conclude that while PGP remains deeply entrenched and sometimes “good enough,” there is no single, universally accepted modern successor that matches its versatility without introducing new drawbacks.

New vulnerabilities and project responses

  • Thread resurfaces the article due to recent CCC “gpg.fail” issues.
  • GnuPG is criticized for declaring some serious bugs “out of scope”/WONTFIX; others are patched but not yet widely shipped.
  • Minisign and age were also affected by some findings, but minisign’s issue is described as much less severe and quickly fixed; the age issue was a simple path-sanitization bug, not cryptographic.
  • Several comments stress that the key security criterion is how maintainers handle bugs, not bug-free code; age’s use of Discord as a primary contact is seen as a bad look.

Replacing PGP/GnuPG: practicality and use cases

  • Many agree age + minisign provide a cleaner stack that covers common needs (file encryption, signing, backups, commit signing), but ecosystem support (e.g. Git forges) lags.
  • One recurring theme: PGP is hard to get rid of because distros and tooling assume it; shipping minisign by default is suggested to break the chicken-and-egg problem.
  • Some users note PGP’s flaws feel “esoteric” compared to their modest threat models; for them, migration pain outweighs theoretical benefits.

Web of Trust, key discovery, and centralization

  • Web of Trust is called “security theater” by some; others point to new designs based on key transparency logs rather than WoT.
  • Keyservers are argued to have mostly “solved” simple key distribution, though modern efforts try to make this auditable and extensible (e.g., auxiliary data for age/minisign/SSH keys).
  • Debate over centralization: one side says E2EE should make server trust irrelevant; the other emphasizes availability and censorship (centralized systems can be blocked, e.g., Signal in some countries).

Sequoia and “modern” OpenPGP vs moving on

  • Some argue the article mostly attacks GnuPG, not PGP, and promote Sequoia (Rust, modern crypto, AEAD, Argon2, PQC) as a sane OpenPGP implementation.
  • The counterargument: once you use new features that break compatibility with most existing PGP clients, you’ve sacrificed the main remaining benefit (interoperability), so you may as well adopt non-PGP tools.
  • There’s disagreement over whether OpenPGP’s 1990s design is “dangerous and antiquated” or merely ugly but serviceable.

Alternatives and their downsides

  • Suggested replacements: Signal (messaging), age (file encryption), minisign/ssh/Sigstore (signing), restic/gocryptfs/age for backups, magic-wormhole for ad‑hoc file transfer.
  • Critiques: some are centralized, require phone numbers, or depend on proprietary infrastructure; availability under blocking and lack of distro integration are concerns.
  • Signal specifically is debated: its cryptography and clients are said to be open source and solid, while others highlight MobileCoin, broken reproducible builds, Google dependencies, and a centralized, number‑tied model as trust and privacy issues.

Email, UX, and protocol design

  • A major line of criticism is that encrypted email (with PGP) is structurally unsafe: users routinely break confidentiality by replying in plaintext, and the protocol doesn’t enforce secure behavior.
  • Some insist this is a client/UI issue; others respond that any protocol relying on clients to “opt in” to security is broken by design.
  • There’s also discussion of MDC/integrity handling (EFAIL vs gpg.fail), with disagreement over whether GnuPG’s error behavior is defensible or dangerously lax.

Complexity, simplicity, and real-world threat models

  • GPG and OpenSSL are seen as huge, complex, and full of “footguns”; minisign/signify are praised for single‑algorithm simplicity (Ed25519) and small attack surface.
  • Others report GPG “just works” for them and question whether the article’s examples (e.g., forwarded plaintext) justify abandoning a tool that appears to have resisted state-level adversaries in practice.
  • Overall, the thread reflects a split: one camp pushing to abandon PGP in favor of narrowly scoped modern tools, another emphasizing PGP’s versatility, installed base, and acceptable security when carefully used.