PGP in 2026: Why the 34-Year-Old Standard Still Matters
It was called “dangerous munitions” by the US government. They were right, and that’s exactly the point.
Tags: OpenPGP, Cryptography, Privacy, Email Security
Reading time: ~12 minutes
Phil Zimmermann released Pretty Good Privacy in 1991. The US government promptly opened a criminal investigation against him for “exporting munitions without a license.” He won. The code was already out. That moment, a lone developer defying an empire with math, encapsulates everything PGP stands for.
Thirty-four years later, OpenPGP (the open standard that grew from Zimmermann’s work, defined in RFC 4880 and updated by RFC 9580 in 2024) remains the gold standard for end-to-end encrypted, cryptographically signed communication. Not because it’s trendy. Because it works, it’s decentralized, and nobody can take it away from you.
The Core Idea: Public-Key Cryptography
PGP is built on asymmetric cryptography. The insight is elegant: you have two mathematically linked keys. What one encrypts, only the other can decrypt. You keep one secret (your private key) and give the other away freely (your public key).
Alice's Public Key → Encrypt message → Ciphertext → Alice's Private Key → PlaintextAnyone encrypts for Alice. Only Alice decrypts.
This solves the ancient “key distribution problem.” Before asymmetric crypto, you had to securely share a secret key before you could communicate securely, a chicken-and-egg nightmare. Now you just publish your public key. Anyone can write to you in total privacy. Only you can read it.
What Actually Happens Under the Hood
Modern OpenPGP (RFC 9580) doesn’t just slap RSA on your message and call it done. It’s a hybrid system with a few distinct moving parts.
1. Session Key Generation
For each message, PGP generates a fresh random symmetric session key (typically AES-256). Symmetric encryption is fast, orders of magnitude faster than asymmetric operations. This is what actually scrambles your data.
2. Asymmetric Key Encapsulation
The session key is then encrypted with the recipient’s public key (using RSA, ECDH, or modern X25519/X448 key exchange). Only the recipient’s private key can recover the session key. This small asymmetric operation is the “envelope seal.”
3. The Signed & Encrypted Packet
The final message contains: the encrypted session key, the symmetrically encrypted payload, and optionally a digital signature. The signature proves the message came from you, not just that it’s encrypted.
# Simplified OpenPGP message structure
PublicKeyEncryptedSessionKey {
key_id: 0xDEADBEEF... # which public key was used
algorithm: X25519 # modern ECDH
encrypted_skey: [AES-256 key, wrapped]
}
SymmetricallyEncryptedData {
cipher: AES-256-GCM
payload: [your actual message, compressed first]
}
Signature {
key_id: 0xSENDER_ID...
hash: SHA-512
signature: [sender's private key signs the hash]
}The Web of Trust: No Certificate Authorities
This is where PGP diverges fundamentally from HTTPS and S/MIME. Your browser’s security model depends on Certificate Authorities, trusted companies (Comodo, DigiCert, Let’s Encrypt) that vouch for identities. When a CA gets compromised or goes rogue, that trust collapses.
PGP takes a different path: the Web of Trust. You sign other people’s public keys to say “I’ve verified this is really them.” Others do the same. Trust becomes a distributed graph, not a hierarchy with a single root. No CA can be compelled to backdoor it. No single point of failure. No corporation in the chain.
⚠ The WoT’s practical problem
The original Web of Trust model requires users to manually verify fingerprints and exchange signed keys, something that never scaled beyond the technical community. Keybase tried to automate it via social proof and largely succeeded before Zoom bought them into mediocrity. In 2026, tools like keys.openpgp.org and Sequoia PGP have modernized the experience considerably.
Signing vs. Encrypting: Two Different Powers
PGP gives you two distinct capabilities that people often conflate:
| Capability | What it does | What it proves |
|---|---|---|
| Encryption | Scrambles content so only the recipient can read it | Confidentiality, nobody else can read this |
| Signing | Attaches a cryptographic proof to your message or file | Authenticity & integrity, this came from me, unchanged |
You can use either alone. Sign a public announcement without encrypting it, now anyone can verify it came from you and wasn’t tampered with. Encrypt a file for a recipient without signing, you get confidentiality but not attribution. Use both together and you get the full picture.
Signing is arguably more useful than encryption in 2026
If you distribute software, configuration files, scripts, or any data people depend on, signing it with PGP is non-negotiable. The Debian and Arch Linux package ecosystems both use OpenPGP signatures for exactly this reason. When your server pulls an updated package, it verifies the signature. Without that, you’re trusting a network path, not the software author.
# Sign a release tarball
gpg --armor --detach-sign myapp-2.1.0.tar.gz
# Produces myapp-2.1.0.tar.gz.asc
# Verify someone else's release
gpg --verify myapp-2.1.0.tar.gz.asc myapp-2.1.0.tar.gz
# Good signature from "Dev Name <dev@example.com>" — or it fails loudly
# Encrypt a file for a recipient (by their key fingerprint)
gpg --armor --encrypt --recipient 0xABCD1234DEADBEEF secret.txt
# Encrypt + sign in one shot
gpg --armor --encrypt --sign --recipient them@example.com message.txtRFC 9580: What Changed in 2024
The crypto world doesn’t stand still, and neither does OpenPGP. RFC 9580, published in 2024, modernized the standard significantly.
New algorithms: Native support for Ed25519 and Ed448 for signatures, and X25519 / X448 for key exchange, the same elliptic-curve primitives trusted by Signal, WireGuard, and SSH. These are faster, produce smaller keys, and have better security properties than the old RSA defaults.
AEAD encryption: Replaced the older MDC scheme with proper authenticated encryption (OCB, EAX, GCM modes). This closes a class of theoretical attacks and brings OpenPGP in line with modern symmetric crypto best practices.
Cleaner key structure: Version 6 keys fix longstanding quirks in how subkeys, binding signatures, and key metadata were handled.
ℹ Practical note
GnuPG 2.4+ supports Ed25519/Ed448 keys. If you’re generating new keys in 2026, use
gpg --full-generate-keyand pick an ECC option. RSA 4096 still works but you’re carrying legacy weight.
Why You Should Still Care in 2026
The obvious objection: “Signal exists. Matrix exists. Why bother with this dinosaur?”
Fair question. Signal is excellent for real-time messaging. But PGP and Signal solve different problems, and the comparison misses what makes PGP uniquely valuable.
1. Asynchronous, long-lived, portable trust
PGP keys live outside any platform. Your key pair from today will verify your signed artifact in 2035, on any system, with any compliant tool. Signal sessions are ephemeral by design. When Signal goes away, your conversation history, and any trust you established, goes with it. A PGP signature on a contract, a software release, or a public statement is a permanent, platform-independent proof.
2. Email is not going anywhere
Email is federated, decentralized infrastructure that has survived 50 years and will survive another 50. Encrypted email via PGP (Thunderbird’s native OpenPGP support) is the only end-to-end encrypted option that works across providers without asking both parties to join the same silo. Proton Mail, Tutanota, and others use OpenPGP internally, and let you exchange encrypted mail with external PGP users.
3. Software and data integrity
If you run servers, you should be verifying the integrity of everything you install. Linux distro packages, Docker base images, Terraform providers, the serious ones are PGP signed. Rolling your own software distribution? Sign your releases. Your users can then verify they’re running exactly what you shipped, not something intercepted or corrupted downstream.
4. No dependency on a company
Signal is a US non-profit, better than a corporation, but still subject to US jurisdiction and ultimately dependent on continued funding and goodwill. PGP is a standard. GnuPG is open source. The math doesn’t have a CEO. This is the case for cryptographic sovereignty: it’s the closest thing we’ve got for written communication and data integrity that no company can be pressured to compromise.
5. Post-quantum: the transition is beginning
The elephant in the room. NIST finalized post-quantum standards (CRYSTALS-Kyber, CRYSTALS-Dilithium) in 2024, and the OpenPGP working group is actively working on PQC integration. The hybrid approach, pairing classical ECDH with a PQC KEM, is how the transition will happen. Because OpenPGP is defined as a protocol, not a product, it can absorb new algorithms without disrupting the ecosystem. Expect PGP implementations to ship PQC hybrid keys within the next 12–24 months.
The Honest Weaknesses
PGP has real problems and you should know them.
Metadata isn’t encrypted. Who sent to whom, and when, is visible. The “to” and “from” fields of a PGP-encrypted email are still cleartext. If traffic analysis is in your threat model, PGP alone doesn’t protect you.
Key management is hard. Losing your private key means losing access to everything encrypted for it. Key revocation requires forethought, generate a revocation certificate before you need it. Subkeys, expiry dates, and smart card offloading are rabbit holes most users never emerge from.
No forward secrecy by default. If your private key is compromised years from now, all past encrypted messages can be decrypted. Signal solves this with ephemeral ratcheting keys. PGP doesn’t. For long-term secret-keeping, this is a genuine concern.
UX is still hostile. This has improved, Thunderbird’s built-in OpenPGP support, GPG Suite on macOS, and tools like Kleopatra are usable, but it’s not frictionless. You won’t get non-technical contacts using it easily.
Getting Started: The Short Version
Generate a modern key pair
# Generate ECC key (Ed25519 primary + Curve25519 encryption subkey)
gpg --full-generate-key
# Choose: (9) ECC (sign and encrypt) → Curve 25519
# Set expiry: 2y is sensible — you can always extend
# List your keys
gpg --list-secret-keys --keyid-format=long
# Export public key (share this freely)
gpg --armor --export you@example.com > pubkey.asc
# Generate revocation cert NOW, store offline
gpg --generate-revocation you@example.com > revoke.asc
# Upload to key server
gpg --keyserver keys.openpgp.org --send-keys YOUR_KEY_IDBack up your private key, properly
gpg --armor --export-secret-keys you@example.com > private-backup.asc
# Encrypt this with a strong passphrase and store it offline.
# Consider paper backup via 'paperkey' for the truly paranoid.Fingerprint verification
Always verify keys out-of-band. Get someone’s fingerprint over a voice call, in person, or via a signed post. A fingerprint looks like:
A3B4 F891 2C3D 4E5F 6A7B 8C9D 0E1F 2A3B 4C5D 6E7FMatch every character. That 40-hex-digit string is your cryptographic identity.
The Bottom Line
PGP won’t replace Signal for your daily chats, and it shouldn’t. But for signing software releases, encrypting sensitive documents, authenticating your identity outside any platform’s control, and building the infrastructure of trust that serious technical work requires, nothing else comes close.
In 2026, with governments globally pushing for backdoors and “lawful access” to encrypted communications, the existence of a mature, open, mathematically sound standard that no company can be pressured to compromise is not a historical curiosity. It’s infrastructure. Use it accordingly.
Further reading
RFC 9580 — OpenPGP (2024 revision) · GnuPG.org — Reference implementation · keys.openpgp.org — GDPR-compliant key server · Sequoia PGP — Modern Rust implementation · Proton Mail — PGP-based encrypted email, accessible entry point
