PGP vs Modern Tools

PGP — Pretty Good Privacy — was revolutionary in 1991 and is now a cautionary tale. Its cryptographic primitives (RSA, SHA, AES) still work fine. Its system design is a 30-year-old set of choices that haven't aged well. This lesson is about why PGP is the wrong default in 2026 and what the modern primitives look like.

What PGP gets fundamentally wrong

The "PGP problem" essay by Latacora is the canonical reference. The short version:

1. Long-lived keys with no forward secrecy

PGP keys live for years. Sometimes decades. If your private key is ever exposed — laptop stolen, hard-drive forensics, malware, court order — every encrypted message you've ever received becomes decryptable.

Modern protocols use ephemeral keys that are derived per-session and discarded. Compromising today's keys tells the attacker nothing about yesterday's traffic.

2. No post-compromise security

Even if you eventually replace a compromised key, PGP gives the attacker an indefinite window to decrypt traffic before you notice. There's no "ratcheting" — no mechanism that automatically heals the conversation after a compromise.

Signal Protocol's Double Ratchet does exactly this: every message rotates keys forward AND mixes in fresh DH material. Even if an attacker reads one message, the next one is unreadable to them.

3. Web of trust nobody uses

PGP's identity model is the web of trust: users sign each other's keys at "key-signing parties," building a graph of "I vouch for this key belonging to this person." In practice:

• Almost nobody attends key-signing parties anymore.
• Most PGP users sign nothing and verify nothing.
• The web of trust collapses into "trust on first use" plus social spam from key-server poisoners.
• Key-servers themselves leak the entire social graph.

Modern tools use simpler trust models: TOFU (trust-on-first-use, like SSH) or identity-bound keys (like FIDO2's attestation, or Signal's safety numbers).

4. Leaky metadata

A PGP-encrypted email reveals:

• Who is talking to whom (envelope headers are unencrypted).
• When they're talking (timestamps).
• The size of each message (often correlates with content).
• The sender's PGP version, locale, and software fingerprint.
• The recipient's key id (public).

Signal hides most of this. Sealed-sender messages don't even reveal who sent the message to anyone but the recipient.

5. Bad defaults, footgun-rich UX

GnuPG — the most common PGP implementation — has a CLI that took 30 years to half-stabilise. Default ciphers, key sizes, and signing options have churned. The 2018 EFAIL vulnerability exploited PGP's HTML email integration to exfiltrate decrypted content over network requests. The fundamental flaw was that PGP had no integrity guarantee — ciphertext could be modified, and the resulting "decrypted" content was rendered.

6. Email is the wrong place

Most PGP traffic is email. Email itself leaks metadata (Subject, To, From, Date, Message-ID). Adding PGP to email is like installing a vault door on a glass house.

What replaced what

Use case	PGP did	Modern tool	Why it's better
Encrypted messaging	gpg --encrypt over email	Signal Protocol	Forward secrecy, post-compromise security, sealed sender
File encryption	gpg -c file.pdf	age	Tiny, modern primitives (X25519+ChaCha20-Poly1305), no key servers
Code-signing releases	gpg --sign --detach-sign	minisign / signify / sigstore	Smaller signatures, no GPG agent, simpler verification
Identity / SSH auth	gpg-agent + smartcards	ssh keys + ssh-agent (or YubiKey FIDO2)	Boring, well-understood, ubiquitous
One-shot file send	Email PGP attachment	magic-wormhole	Peer-to-peer; SPAKE2-protected short code; no key management
Encrypted backup	gpg --symmetric	age + a strong passphrase, or restic --encryption	Modern primitives; restic adds dedup

Each tool, briefly

Signal Protocol

The gold standard of E2E encrypted messaging. Components:

• X3DH: initial key agreement using a long-term identity key, a signed pre-key, and a one-time pre-key. Provides forward secrecy AND authentication.
• Double Ratchet: per-message key rotation combining a symmetric ratchet (every message) and a DH ratchet (every reply).
• Sealed sender: even Signal's servers don't see who sent which message.
• Safety numbers: humans verify the connection by comparing 60-digit fingerprints.

You don't usually implement Signal yourself — use libsignal or build on top of an existing client.

age

A 2019 file-encryption tool by Filippo Valsorda and Ben Cartwright-Cox. Design goals:

• Small spec, small implementation.
• Sane defaults: X25519 KEM + ChaCha20-Poly1305.
• No key servers, no web of trust — recipients are bare X25519 public keys.
• One-shot or streaming.
• Encrypted output is binary (or short ASCII via --armor); no leaky metadata headers.

# Generate a recipient
age-keygen -o ~/.age/key.txt
# Output: public key age1qrysxn...

# Sender encrypts
age -r age1qrysxnxa00... secret.txt > secret.age

# Recipient decrypts
age -d -i ~/.age/key.txt secret.age > secret.txt

That's the whole tool. It's 600 lines of Go.

minisign

Frank Denis's signing tool. Drop-in replacement for gpg --detach-sign. Ed25519 keys, ~100-byte signatures. Used by Zig, dnscrypt, and many other security-conscious projects.

sigstore (cosign)

The Linux Foundation's modern code-signing system. Key innovations:

• Keyless: ephemeral signing keys minted from your OIDC identity (Google, GitHub, etc.).
• Fulcio: the CA that issues short-lived signing certs.
• Rekor: a transparency log so anyone can audit signatures.
• Cosign: the CLI for signing containers and attestations.

Used by Kubernetes, Istio, Tekton, and an expanding share of OSS supply chain.

magic-wormhole

Brian Warner's one-shot file transfer. Run on both sides, type a code phrase ("4-quasar-radium"), files transfer peer-to-peer. SPAKE2-derived shared secret authenticated by the short code. Zero setup; zero key management.

# Sender
wormhole send presentation.pdf
# → Code: 4-quasar-radium

# Receiver
wormhole receive 4-quasar-radium

If you've ever wanted to send a file across a coffee shop and didn't want to deal with email, Dropbox links, or AirDrop limits — this is the tool.

Encrypted email — what to actually use

If you really need encrypted email, the answer is mostly: don't. Use a different tool:

• Signal for any conversation that needs end-to-end encryption.
• Proton Mail / Tutanota if email is non-negotiable. They handle the key management opaquely with reasonable defaults.
• age + email-as-transport for files: encrypt with age, attach the .age file to a normal email.

Plain PGP email is broken in EFAIL-class ways and leaks metadata regardless. If your threat model is "casual eavesdropping," PGP-encrypted email "kinda works." If your threat model is anything serious, it doesn't.

When PGP is still legitimately the right tool

Real cases where PGP is hard to replace today:

• Debian / Linux package signing. The infrastructure is built on GPG. Migration to sigstore-style flows is happening but slowly.
• OpenPGP smartcards / YubiKey OpenPGP applet. A real, well-tested way to keep an SSH/signing key on a hardware token.
• Legacy systems that only accept PGP. CSV with encrypted-email-only handoff to government / banking processes.

If you're doing one of these, fine. If you're considering picking up PGP today for a new project, almost always there's a better tool.

What this lesson asks of you

The playground walks you through 5 contexts (encrypted messaging, sending a file, signing a release, getting a one-time secret to a colleague, email encryption) and asks you to pick the right tool. The visualizer compares the trust models — PGP's web of trust, TOFU, identity-bound, sigstore's transparency-log model — side by side so you can see why "trust" looks different in each.