PGP encryption: keys, signatures, and what they actually protect

What PGP actually is

PGP (Pretty Good Privacy) is a standard for protecting files and messages with asymmetric cryptography. “Asymmetric” means each person holds a key pair: two mathematically linked keys where one locks what the other unlocks. The standard is implemented today by GnuPG (the gpg command) and OpenPGP-compatible tools; the file format extensions you’ll see are .pgp, .gpg (binary) and .asc (ASCII-armoured text, safe to paste into email).

PGP solves two distinct problems with the same key-pair primitive:

1. Secrecy — only the intended recipient can read the file. Done by encrypting with the recipient’s public key.
2. Authenticity — the recipient can verify the file came from you and was not altered. Done by signing with your own private key.

The two are independent — you can encrypt without signing, sign without encrypting, or do both. Production workflows that exchange sensitive files (B2B EDI, contracts, finance feeds) almost always do both.

The cheat sheet

If you only remember one thing about PGP, remember this table — it answers “which key do I use?” for every action.

The symmetry is the whole insight: encryption uses the recipient’s keys; signing uses the sender’s keys. Once you internalise that, the four scenarios below are just two halves of the same primitive.

The four scenarios

Encrypt-only (secrecy without identity)

Alice wants to send Bob a file that nobody else can read. She encrypts it with Bob’s public key. Anyone could have sent the file (anyone can get Bob’s public key), but only Bob can read it.

Sign-only (identity without secrecy)

Alice publishes a file and wants readers to know it came from her and hasn’t been tampered with. She signs it with her private key. Anyone can read the file; anyone can also verify the signature using Alice’s public key.

This is the model for software releases: the binary is public; the detached .sig file proves Alice (or the project) actually produced this binary.

Combined (the standard for two-party exchange)

Alice signs the file with her private key, then encrypts the result with Bob’s public key. Bob decrypts with his private key, then verifies the signature using Alice’s public key. Both protections in one wrapped artifact.

Step through the flow to see which key does which job at each stage — that is the entire mental model:

The order matters: sign first, then encrypt. If you encrypt first and sign the ciphertext, a malicious party can strip the outer signature and re-sign the ciphertext as themselves, claiming they sent the message. Signing the plaintext binds the identity to the content, which is what you actually care about.

Symmetric (password-only, no keys)

You can also use PGP without any keys — just a password. The file is encrypted with a key derived from the passphrase. Anyone who knows the passphrase can decrypt it. This is the right shape for personally archiving a file (“I want a password-protected backup”), not for sending to another person, because now you have a passphrase-distribution problem instead of a key-distribution problem.

What the commands look like

A few gpg commands that map directly onto the scenarios above. The agent running these is assumed to have already imported the relevant keys with gpg --import.

# Output: filename.txt.gpg
gpg --recipient [email protected] --encrypt filename.txt

# --sign uses your default private key (asks for your passphrase)
gpg --sign --encrypt --recipient [email protected] filename.txt

# Prints "Good signature from Alice <…>" if the signature checks out
gpg --decrypt filename.txt.gpg > filename.txt

gpg --symmetric filename.txt

The --decrypt step both decrypts and verifies any signature it finds. If the signature is missing or doesn’t validate, gpg says so — but it still writes the decrypted file, so script your verification step explicitly (--status-fd or check the exit code) rather than relying on the human reading the stderr.

Encryption vs. signing — the difference in one analogy

The two are orthogonal. Encryption-without-signing means “I know nobody else read it, but I don’t know who sent it.” Signing-without-encryption means “I know who wrote this and it wasn’t changed, but anyone could have read it.” Combined gives you both.

File extensions you’ll see

• .asc — armoured (text-encoded) form of a key, message, or signature. Looks like a block of letters and digits. Pasteable into email.
• .gpg / .pgp — binary encrypted file. The standard format for an encrypted artifact.
• .sig — a detached signature. Lives next to the original file (installer.exe and installer.exe.sig). The original is untouched; the .sig proves the original is authentic.

Detached signatures are the right shape when the file should stay openable by tools that don’t speak PGP (a Windows installer should still double-click), while still being verifiable by tools that do.

Operational rules — the ones that bite

1. Never share your private key

   Anyone who has it can read your incoming messages and forge your signature on outgoing ones. The blast radius is total and retroactive.

2. Never lose your private key

   Without it, you cannot decrypt any past message that was encrypted to you. There is no recovery. Back up the encrypted private key file (it’s protected by your passphrase) to durable storage.

3. Never forget your passphrase

   The passphrase is what unlocks the private key file. Without it, the file is useless. Use a password manager; the passphrase is one of the highest-stakes secrets you’ll ever hold.

4. Publish your public key fingerprint somewhere durable

   A public key file is easy to swap on a hostile network. Recipients verify the public key by its 40-character fingerprint, which they should obtain through a different channel (your printed business card, a signed git tag, an HTTPS page they trust). The fingerprint is what binds the key to the person.

The footguns

Other production-grade traps:

• Trusting an unverified public key. A public key sitting in an email is only useful if you’ve verified its fingerprint through a separate channel. Otherwise an attacker on the network can substitute their own key, and everything you encrypt with it is readable by them. PGP doesn’t solve key-distribution; you still need a way to bootstrap trust.
• Treating “no signature” as “valid”. A workflow that decrypts and checks “did it succeed?” passes for any unsigned file. If your protocol requires signed input, the decryption step must also assert a valid signature was present — otherwise an attacker who learns the recipient’s public key can ship unsigned files into the pipeline.
• Leaving plaintext on disk. gpg --decrypt foo.gpg > foo.txt writes plaintext that now lives on the filesystem until you remember to delete it. For sensitive files, stream the decrypted output directly into the consuming process (gpg --decrypt foo.gpg | tool) and let the plaintext exist only in memory.
• Conflating PGP with TLS. TLS protects data in transit between two endpoints; PGP protects data at rest (and end-to-end through whoever holds it in between). You usually want both. TLS does nothing for a file stored on the recipient’s disk; PGP does nothing for the in-transit metadata that surrounds it.

What to remember

For the inverse problem — values that should never be decryptable, like passwords — see 0014 Hashing passwords (not encrypting them) · System Design . Encryption is for things you need to read back; hashing is for things you never should.