TL;DR
PGP’s design, originating in the 1990s, has accumulated compatibility and security liabilities that modern cryptography avoids. Engineers and cryptographers criticize its complexity, poor defaults, brittle authentication, leaking metadata and lack of forward secrecy.
What happened
A long-standing critique of Pretty Good Privacy (PGP) argues the system is fundamentally mismatched to modern cryptographic expectations. PGP’s packet-based archive format and many legacy encodings produce extreme complexity for implementers; key handling includes keys, subkeys, key IDs and keyservers with fragile semantics. The protocol relies on outdated primitives and defaults (for example, older RSA sizes, 64-bit-block ciphers in CFB mode, and a legacy S2K password KDF) and layers ad-hoc fixes like the MDC (a SHA-1 checksum of plaintext) that can be stripped or mishandled. That brittleness manifests in user-unfriendly workflows, encouragement of long-lived root keys and a “web of trust” that the critique finds unreliable. PGP also links messages to key identifiers and keyservers, leaking metadata, and it lacks forward secrecy, making recorded ciphertexts vulnerable if keys are later compromised.
Why it matters
- Complex, brittle formats increase the surface for implementation bugs and parsing attacks.
- Outdated primitives and poor defaults mean users may get weaker protections than they expect.
- User-unfriendly key management and long-lived keys raise the blast radius of compromises.
- PGP’s metadata model and keyserver usage expose social graph information about correspondents.
Key facts
- PGP’s message format is a typed packet archive with at least eight different length-encoding variants and nested subpackets.
- The protocol distinguishes keys and subkeys, key IDs, keyservers, signatures, and multiple keyrings, contributing to complexity.
- Common legacy defaults can include 2048-bit RSA and a 64-bit-block cipher (CAST5) in CFB mode; OpenPGP also specifies an S2K password KDF.
- A mitigation called the MDC appends a SHA-1 checksum of plaintext before encryption; that construction can be removed by truncating the last 22 bytes of ciphertext.
- Reference implementations can expose unauthenticated plaintext to callers even when the MDC validation fails.
- Some modern clients or implementations (example: Sequoia PGP) have chosen AEAD modes like AES-EAX, but many existing installs do not interoperate with those choices.
- PGP promotes long-term root keys and a web-of-trust model (key signing parties, publishing fingerprints and keyservers), which the critique argues is ineffective in practice.
- PGP lacks forward secrecy, so an attacker who later obtains a long-term key can retrospectively decrypt captured messages.
- Key identifiers and use of public keyservers can reveal who is communicating with whom, leaking metadata.
What to watch next
- Client and installed-base support for modern authenticated-encryption modes (AEAD) and interoperable defaults such as AES-GCM or other widely supported AEADs.
- Changes in key distribution practices and keyserver behavior, and whether the web-of-trust model is revised or deprecated by major projects.
- not confirmed in the source
Quick glossary
- PGP / OpenPGP: A family of standards and implementations for encrypting and signing data and email; in this critique the umbrella term covers both the RFCs and common implementations like GnuPG.
- AEAD: Authenticated Encryption with Associated Data: cryptographic modes that provide confidentiality and integrity/authentication in a single primitive.
- MDC: Modification Detection Code: an OpenPGP-era construct that attaches a checksum (historically SHA-1) to plaintext before encryption to detect tampering.
- Keyserver: A networked service that stores and distributes public keys and key metadata; keyservers are commonly used in PGP workflows.
- Forward secrecy: A property of communication protocols where compromise of long-term keys does not allow decryption of past recorded sessions.
Reader FAQ
Is PGP considered secure today?
The source argues PGP has many structural and practical weaknesses—outdated defaults, brittle authentication, metadata exposure and lack of forward secrecy—so it is widely criticized by modern cryptographers.
Can PGP be fixed by updating algorithms or using hardware tokens?
Some implementations have added modern primitives (for example, AEAD modes), and hardware tokens can protect keys, but the critique emphasizes that compatibility with a large installed base and PGP’s design make full remediation difficult; widespread reliance on hardware tokens is described as uncommon.
Is PGP appropriate for secure messaging?
According to the source, PGP is a poor fit for conversational secure messaging because it lacks forward secrecy and has usability and metadata-leakage issues.
Should I migrate away from PGP now?
not confirmed in the source
▶ Table of Contents (21 sections) Cryptography engineers have been tearing their hair out over PGP’s deficiencies for (literally) decades. When other kinds of engineers get wind of this, they’re…
Sources
- The PGP problem (2019)
- The PGP Problem: A Critique – The Call of the Open Sidewalk
- The PGP Problem: A Critique (2020)
- Why haven't GPG/PGP seen better user adoption?
Related posts
- Reassessing Tony Hoare’s ‘Billion Dollar Mistake’ for Null Pointers
- Maybe Comments Should Explain ‘What’ — Rethinking Comments in Code
- How a Christmas beach moment with my partner changed Google Photos use