In 1991, Phil Zimmermann released a small program called Pretty Good Privacy and almost went to prison for it. The U.S. government argued that strong cryptography was a munition, and that publishing it amounted to arms exporting. Three decades later, PGP is a quiet workhorse: it signs Linux package releases, encrypts journalist drops, gates access to npm publishing, and still glues together a surprising amount of email between security-conscious humans. If you have ever stared at a -----BEGIN PGP PUBLIC KEY BLOCK----- in a README and wondered what to do with it, this is for you.
What PGP Actually Is
PGP is not one algorithm. It is a message format and a protocol that combines several primitives into a usable envelope. The current open standard, OpenPGP, is defined in RFC 4880 and its successors. GnuPG (gpg) is the most widely used implementation; there are also libraries like Sequoia, OpenPGP.js, and BouncyCastle.
Underneath the OpenPGP wrapper, three things happen:
- Asymmetric encryption (RSA, ECDH on Curve25519, etc.) handles key exchange.
- Symmetric encryption (AES-256, ChaCha20) handles the actual message body.
- Hashing (SHA-256, SHA-512) is used for signatures and integrity checks.
PGP itself is the glue that decides which key encrypts what, how it is packaged, and how the receiver tears it back apart. The fascinating bit is that PGP almost never uses the public-key algorithm to encrypt your actual message — it only uses it to encrypt a one-time key. Read on.
Public Keys, Private Keys, and Why You Need Both
flowchart TB
subgraph Bundle["Modern PGP key bundle"]
Primary["Primary key<br/>(identity, signs other keys)"]
SubE["Subkey<br/>(encryption)"]
SubS["Subkey<br/>(signing, day-to-day)"]
SubA["Subkey<br/>(authentication, optional)"]
Primary -- certifies --> SubE
Primary -- certifies --> SubS
Primary -- certifies --> SubA
end
Primary -. kept offline / on hardware token .-> Vault[(Cold storage)]
SubE -. used daily .-> Daily["Laptop / phone"]
SubS -. used daily .-> Daily
A PGP identity is a key pair. The public key you hand out freely; the private key you guard like a passport.
Public key → encrypt messages to you, verify signatures from you
Private key → decrypt messages sent to you, sign messages from youInternally, a modern PGP key is usually a bundle: a primary key plus one or more subkeys. The primary key proves identity (and signs other keys). Subkeys handle day-to-day encryption and signing, and can be rotated or revoked without invalidating your whole identity. This is why a long-lived PGP key from 2008 is still useful in 2026 even if its encryption subkey was rotated three times.
If you want to see the math up close, generate a key pair with our RSA key generator — PGP RSA keys use the same primitives, just wrapped in a different envelope. Modern PGP defaults are now Curve25519 (Ed25519 for signing, X25519 for encryption), which produce much smaller keys than RSA at the same security level.
Hybrid Encryption: The Trick That Makes PGP Fast
Public-key crypto is slow. Encrypting a 50 MB attachment with RSA directly would be painful and produce a huge ciphertext. So PGP cheats — the same way TLS cheats. It uses asymmetric crypto only to ferry a small symmetric key.
Here is the actual flow when Alice encrypts a file for Bob:
sequenceDiagram participant A as Alice participant Msg as PGP message participant B as Bob A->>A: Generate random session key (AES-256, one-time) A->>A: AES-encrypt(message body, session_key) → C_body A->>A: RSA-encrypt(session_key, Bob_public_key) → C_key A->>Msg: Pack [C_key, C_body] as OpenPGP packets Msg->>B: Email / file transfer B->>B: RSA-decrypt(C_key, Bob_private_key) → session_key B->>B: AES-decrypt(C_body, session_key) → message body
- Alice generates a random session key (a fresh AES-256 key, used once).
- Alice encrypts the message body with that session key using AES.
- Alice encrypts the session key with Bob's public key using RSA or ECDH.
- Alice bundles the two ciphertexts together. That bundle is the PGP message.
When Bob decrypts:
- He uses his private key to recover the session key.
- He uses the session key to decrypt the body.
[ E_pub(session_key) ] ← small, asymmetric
[ E_session(message) ] ← large, symmetricIf Alice wants to send the same file to three recipients, she encrypts the session key three times (once per public key) but only encrypts the message body once. That is why a PGP message can have multiple recipients without ballooning in size. The same idea powers encrypted email mailing lists.
If you are curious how the symmetric half feels in isolation, our AES text encryptor lets you encrypt a string with a passphrase — that is essentially the inner layer of every PGP message.
Signing vs Encrypting (They Are Not the Same Thing)
This trips up newcomers. Encryption scrambles content so only the holder of a private key can read it. Signing does the opposite — it leaves the content in the clear and attaches a proof that you wrote it.
You can do either, both, or neither:
- Encrypted only: anyone could have written it, but only the recipient can read it.
- Signed only: everyone can read it, and everyone can verify who wrote it. Used for software releases.
- Signed and encrypted: confidential and authenticated. Used for sensitive email.
A signature is created by hashing the message and encrypting that hash with your private key. Anyone with your public key can decrypt the hash and recompute it themselves — if the two match, the message is authentic and unmodified.
flowchart LR
subgraph SignSide["Signer (private key)"]
M1[Message] --> H1[SHA-256]
H1 --> Hash1["digest"]
Hash1 --> Enc[("Sign with<br/>private key")]
Enc --> Sig["signature.asc"]
end
subgraph VerifySide["Verifier (public key)"]
M2[Same message] --> H2[SHA-256]
H2 --> Hash2["digest'"]
Sig --> Dec[("Verify with<br/>public key")]
Dec --> Hash3["digest from sig"]
Hash2 --> Cmp{Equal?}
Hash3 --> Cmp
Cmp -- yes --> OK[Authentic and intact]
Cmp -- no --> Bad[Tampered or wrong signer]
end
# Sign a release tarball, producing release.tar.gz.asc
gpg --detach-sign --armor release.tar.gz
# A user verifies with your public key
gpg --verify release.tar.gz.asc release.tar.gzDetached signatures (.asc or .sig files) are how Linux distros, Tor, and nearly every serious open-source project distribute trustworthy binaries. The signature is small, the file is unchanged, and verification is offline.
The Web of Trust (and Why TOFU Won)
flowchart LR You((You)) Alice((Alice)) Carol((Carol)) Dave((Dave)) Bob((Bob)) Eve((Eve)) You -- "trust" --> Alice You -- "trust" --> Carol Alice -- "signed" --> Bob Carol -- "signed" --> Bob Dave -- "signed" --> Bob Eve -- "signed" --> Bob Bob -- "appears trustworthy via Alice + Carol" --> You
PGP's original answer to "is this really Bob's key?" was the web of trust: humans sign each other's keys after meeting in person, building a graph of vouchers. If three people you trust have signed Bob's key, you have reasonable evidence it is really his.
In practice, the web of trust never scaled outside niche communities. Key-signing parties were awkward, keyservers got spammed, and most users had no path to anyone else. Two pragmatic alternatives took over:
- TOFU (trust on first use): pin the key the first time you see it, warn loudly if it changes. This is what SSH does and what most modern PGP clients lean on.
- Out-of-band verification: compare a fingerprint over a different channel — a Signal message, a printed business card, a published Keybase profile, a verified domain.
A PGP fingerprint is a SHA hash of the key material, usually shown as a 40-hex string in groups of four:
3A2F 8C1D 5B6E 9F0A 4C73 1E22 8D5B A7F1 6E0C 9D88That is what you check. If the fingerprint matches what Bob put on his website, the key is his. The same idea applies to SSH — see our SSH public key fingerprint tool for that side of the world. And while X.509 certificates (the kind used in TLS) solve the trust problem with hierarchical CAs instead of a peer graph, the underlying primitives are nearly identical.
What a PGP Message Actually Looks Like
When you ASCII-armor a PGP message, you get the familiar block format. Underneath, it is a sequence of packets defined by RFC 4880 — a public-key encrypted session key packet, then a symmetrically encrypted integrity-protected data packet, possibly a signature packet, optional compression, and so on.
-----BEGIN PGP MESSAGE-----
hQEMA1xK... (public-key encrypted session key)
0kgBxe... (symmetrically encrypted data)
=qZ2A
-----END PGP MESSAGE-----The =qZ2A at the end is a CRC-24 checksum, not a signature. The whole armor is just base64 with a header so it survives email gateways that mangle binary data.
You can craft and inspect your own messages in the browser with our PGP encrypt/decrypt tool, which uses OpenPGP.js so the keys never leave your machine.
Where PGP Still Fits in 2026
PGP has well-earned criticism. The user experience is rough, key management is mostly manual, and there is no forward secrecy in the classic email model — if your private key leaks, every message ever sent to you can be decrypted retroactively. For interactive chat, Signal and other modern protocols are simply better.
Still, PGP wins in a handful of places that have not gone away:
- Software supply chain: Debian, Arch, npm publishers, Docker image signing (via Sigstore, which uses related concepts), and most release artifacts are PGP-signed. The GnuPG handbook is still the canonical reference for this workflow.
- Source-code signing: Git's
--gpg-signproduces signed commits and tags, used by curl, Linux kernel maintainers, and every project that publishes verified releases on GitHub. - Long-lived archives: encrypting backups or sensitive documents at rest, where you control both keys.
- Journalist and source contact: SecureDrop, ProtonMail, and most "contact me securely" pages on news sites still publish a PGP key. The EFF's intro to public-key crypto is the friendliest on-ramp here.
- Email when both ends already use it: clunky, but private when configured carefully.
For history buffs and the deep dive on Phil Zimmermann's near-prosecution, Wikipedia's PGP article is a good rabbit hole.
Practical Habits If You Are Going to Use It
A few habits that separate "I generated a key once" from "I actually use PGP":
- Use subkeys. Keep your primary key offline (a hardware token or an air-gapped machine), put encryption and signing subkeys on your daily driver. If your laptop is compromised, you revoke the subkey, not your identity.
- Set an expiry. Two years is a reasonable default — you can extend it from the offline primary key. A lost key without an expiry haunts the keyservers forever.
- Generate a revocation certificate immediately and store it somewhere safe. If you lose your private key, this is the only way to tell the world the key is dead.
- Publish your fingerprint, not just your key. On your website, in your email signature, on your business card. A fingerprint is small, a key is not.
- Rotate session keys, not user identities. That is what subkeys are for. Resist the urge to make a new identity every couple of years.
If you only remember one thing: PGP is hybrid encryption with a trust model bolted on. The math is sound, the math is not the hard part. The hard part is the human — getting the right key, keeping the private one private, and not losing it. Get those right and PGP is still, three and a half decades later, pretty good privacy.
FAQ
Should I use PGP for encrypted messaging in 2026?
For interactive chat with another human, no — Signal is better in every way (forward secrecy, automated key exchange, modern UX). PGP shines for software signing, long-lived archive encryption, and asynchronous email when both ends are already set up. Pick the right tool: Signal for chat, PGP for signed releases and air-gapped archives.
What's the difference between PGP, GPG, and OpenPGP?
OpenPGP is the open standard (RFC 4880 and successors). GnuPG (gpg) is the most widely used free implementation of that standard. PGP was the original 1991 program by Phil Zimmermann; the name now mostly refers to the protocol family rather than any specific tool. In daily usage they're treated as synonyms.
Why does PGP not have forward secrecy?
Because the same long-lived key decrypts every message ever sent to you. If your private key leaks today, every email ever encrypted to you, even from years ago, can be decrypted. Modern protocols like Signal use ephemeral key exchanges (X3DH + double ratchet) so each message has its own key. PGP's email-friendly model trades forward secrecy for offline asynchronous delivery.
RSA-4096 or Curve25519 for a new PGP key?
Curve25519 (Ed25519 for signing, X25519 for encryption). Smaller keys, faster operations, equivalent or better security than RSA-4096. The only reason to pick RSA in 2026 is if you need to interoperate with old GnuPG versions (<2.1) or hardware tokens that don't support EdDSA. Modern keys are EC by default.
How long should a PGP key be valid?
Two years is a reasonable default — long enough to avoid constant rotation, short enough that lost keys don't haunt keyservers forever. Extend from the offline primary key as expiry approaches. Setting "no expiry" is a mistake; a key you lose without a revocation certificate becomes a tombstone on the global keyservers.
What if I lose my PGP private key?
If you generated a revocation certificate, publish it and people will know the key is dead. If you didn't, the key sits on keyservers indefinitely as a zombie — people might still encrypt to it. Always generate a revocation cert immediately after key creation and store it somewhere separate from your private key (printed paper in a safe, USB drive in another building).
Why does PGP use both asymmetric and symmetric encryption?
Speed and message size. Asymmetric crypto (RSA, ECDH) is roughly 1,000× slower than AES and produces ciphertext bloat proportional to the data. So PGP encrypts the actual message body with a fast random AES key, then encrypts only that small AES key with the recipient's public key. Same trick TLS uses for the same reason.
Are PGP keys quantum-safe?
No. RSA, ECDH, and Ed25519 all fall to Shor's algorithm on a sufficiently large quantum computer, which would let an attacker decrypt every PGP message ever sent to you using your public key. Such a computer doesn't exist yet, but encrypted messages stored today could be retroactively decrypted. NIST's post-quantum algorithms (ML-KEM, ML-DSA) are starting to appear in OpenPGP draft specs but aren't widely deployed yet.