A practitioner's guide to PGP / GPG

The "PGP is dead" debate, briefly

Every couple of years a respected cryptographer publishes a piece arguing that PGP is dead, dying, or should be put out of its misery. The arguments are usually right in their narrow scope — PGP is bad for sync messaging, the UX is terrible, the metadata is unprotected, the SKS keyserver network is a tyre fire, the key model is a liability — and usually overstated as a general claim.

I've used OpenPGP / GnuPG since the late 1990s. I keep using it for the things it is genuinely good at, while reaching for Signal, age, sequoia, minisign, and the rest of the modern toolkit when they are the better fit. The honest framing isn't "PGP yes / PGP no" but "match the tool to the job".

Here is the framing I actually use:

Use Signal for synchronous person-to-person and small-group messaging. Forward secrecy, sealed sender, well-funded, well-audited, near-universally available. Nothing else competes for that workload.
Use age (or the rage / minisign family) for file encryption with a clean, modern UX. Small key size, no committee, no legacy. If you want to encrypt a backup or hand a file to a colleague securely, age is the right answer.
Use minisign / signify / sequoia for software-artefact signing. The release-engineering use case has tooling that is far cleaner than gpg.
Use OpenPGP / GnuPG for: long-form email where the recipient already has a key; multi-recipient encryption with a stable key set (a security disclosure mailbox, an at-rest archive); long-lived attestations where you specifically want the verifiable identity ladder; and any workflow where the counter-party expects PGP and won't change.

None of this is moral. Cryptographers who say "PGP is bad" are usually right about the specific bug they are documenting; cryptographers who say "PGP is fine" are usually right about the specific workflow they are defending. Pick the tool. Move on.

What you need to know about my key

The current public key for security@peterbassill.com and consulting@peterbassill.com lives at /pgp.asc on this site, and is referenced from /.well-known/security.txt as the Encryption: field.

The fingerprint will be published on this page once the current key is generated and rolled into production. Until then, please follow the encrypted-contact page for the right channel for sensitive matters.

A few operational notes that matter for verification:

I rotate signing subkeys annually and encryption subkeys roughly every two years. The primary identity key is long-lived. If you have an older key on file, it should still verify signatures from previous years; check the subkey expiry against the date of the message.
I do not upload to the SKS keyserver network. Use the copy at /pgp.asc on this site, or fetch via the OpenPGP Web Key Directory (WKD) if your client supports it.
If you want to verify the fingerprint out of band, ask me on Signal or in person at a conference. I will read the fingerprint back to you. Do not trust a fingerprint a website tells you without a second channel.

How to install

macOS

GPG Suite is the long-running Mac front-end and Mail.app integration. Free for the command-line tools (which is what you actually need); the Mail.app plug-in is paid. If you live on the command line, just brew install gnupg and skip the GUI.

Windows

Gpg4win bundles GnuPG itself plus the Kleopatra key-manager and the GpgOL Outlook plug-in. Donate if you can — the project is run by a small German team on tight resources.

Linux

Your distribution has it: apt install gnupg, dnf install gnupg2, pacman -S gnupg. Pin the GUI of your choice on top — Seahorse on GNOME, Kleopatra on KDE — or stay on the CLI.

Mobile

Android: OpenKeychain. Open source, well-maintained, integrates with K-9 Mail, FairEmail, and Thunderbird Mobile.
iOS: Canary Mail or iPGMail. Both are paid; both work. iOS does not provide a system-wide PGP keyring, so the choice locks you to that app.

Hardware-key storage

If you are doing anything serious, your private key should live on a hardware token, not on disk. Yubikeys support OpenPGP card mode out of the box. OnlyKey and Nitrokey are good open-hardware alternatives. Generate the key on the token, not on a host you then have to forget about. The drduh YubiKey-Guide is the canonical walk-through and what I recommend new starters work through.

A worked example: send me an encrypted message

Use this as a practice run. Even if you have nothing sensitive to say, it'll exercise the toolchain end-to-end so it's familiar when you do.

1. Get my key

curl -sLO https://www.peterbassill.com/pgp.asc
gpg --import pgp.asc

Or, if your client supports WKD, just type my email address — most modern clients (Thunderbird, Mailpile, Canary) will auto-discover.

2. Verify the fingerprint

List what you imported:

gpg --list-keys --fingerprint security@peterbassill.com

Compare the fingerprint against the one published here on this page and at least one other channel — Signal, in person, a colleague who has signed my key, or a recent conference talk. If the fingerprint matches both, sign the key locally so your client trusts it:

gpg --lsign-key <fingerprint>

3. Compose

Write a plain-text message in a file. Don't use HTML. Don't paste the body into a webmail compose box if you can avoid it — webmail can leak drafts and decrypted plaintext via auto-save.

4. Encrypt

gpg --armor --encrypt --recipient security@peterbassill.com message.txt

That produces message.txt.asc: ASCII-armoured ciphertext you can paste into an email. Or, on the command line:

gpg --armor --encrypt --recipient security@peterbassill.com -o - message.txt | mail -s "PGP test" security@peterbassill.com

5. Send

Email me the armoured block, with a subject line that does not contain the secret bit (subjects are sent in cleartext over SMTP). I will reply encrypted to your key — make sure your From: address has a public key attached, or include yours in your message body.

6. Verify the reply

Decrypt my reply with:

gpg --decrypt reply.eml.asc

You'll see "Good signature from Peter Bassill <…>" — that's the assertion you wanted. If you don't see it, check that you've signed my key locally; otherwise the signature is valid but untrusted.

Common pitfalls

Subject lines. SMTP sends subjects in plaintext. Don't put the secret in the subject. "PGP test" is fine; "Password for the production database" is not.
Drafts in webmail. Many webmail clients auto-save drafts of decrypted plaintext. Compose offline if it matters.
Reply chains. If you reply with quoted plaintext, you've leaked it. Strip quoted text or only use PGP for one-shot messages.
Forgotten passphrases. No recovery, ever. Back up your key on an offline encrypted volume kept somewhere physically safe (a safe-deposit box is not paranoid; it's prudent).
Key expiry. Set an expiry of 1-2 years, not "never". The expiry is your free key-rotation deadline.
Trusting the keyservers. The classic SKS keyserver pool was poisoned in 2019 with attacker-controlled signature flooding. The modern alternatives (keys.openpgp.org, the Web Key Directory) are cleaner. WKD is the modern default and what I publish to.

What about Signal?

If your message is "we should talk", use Signal. The public-key cryptography you actually want for everyday secure messaging — forward secrecy, sealed sender, deniable authentication, modern AEAD — Signal does better than PGP. PGP is the wrong tool if you are messaging a real-time recipient who has Signal too.

Use PGP when the workflow demands it: legacy email, multi-recipient long-lived archives, security disclosures to a shared mailbox, file signatures, archival evidence. Use Signal for everything else.