Algorithm choice (Ed25519 + Curve25519 vs RSA-4096), subkey structure (offline primary + signing/encryption subkeys), passphrase hygiene (diceware), backup strategy (paperkey + 3-2-1), expiry policy (1–2 years), and the revocation certificate you should generate at creation time and store separately.
The single most important step in using PGP is the key generation ceremony. Done badly, the rest of the protocol stops protecting you. Done well, the key survives a decade of mail-client churn, OS reinstalls, lost laptops, and forgotten passphrases — without ever needing to re-issue.
This part is the one place I'm prescriptive instead of descriptive. There are sane defaults and there are bad ones; the gap between them is the difference between "PGP works for you" and "you'll be regenerating a key in two years and asking your correspondents to re-trust it."
OpenPGP supports many algorithms. The two reasonable choices in 2026 are:
Ed25519 / Curve25519 (ECC). Signing key is Ed25519, encryption subkey is Curve25519 (X25519). Modern, fast, small (~256-bit keys instead of RSA's 4096-bit), and standard since RFC 9580 (2024). Every current PGP client supports it. This is the default for new keys generated by Thunderbird, GPG Suite, Mailvelope, and Kleopatra.
RSA-4096. Older, slower, larger keys, but supported by every PGP client ever shipped. Choose RSA only if you correspond with someone using a very old client (e.g. a corporate gateway running gnupg 1.4) that doesn't speak ECC.
Don't choose:
gpg --full-generate-key walks the algorithm picker. Pick "ECC and ECC," then "Curve 25519." Or use the GUI: Thunderbird, Kleopatra, GPG Keychain, and Mailvelope all default to ECC for new keys.
A well-generated PGP key isn't one key — it's a primary key (used only to certify subkeys) plus 2–3 subkeys for daily operations:
Why split? The primary key holds your identity — your name, email, fingerprint, and the certifications other people made on your key. Re-issuing the primary key means re-publishing and asking everyone to re-trust. Subkeys, by contrast, are revocable and replaceable without touching the primary. If your laptop is compromised, you revoke the affected subkey, generate a new one, and the primary identity (and all the trust signatures on it) survives.
This is important enough that the recommended setup keeps the primary key offline — on an encrypted USB stick or a smartcard — and only the subkeys live on the laptop. gpg --edit-key <fingerprint> lets you remove the primary's secret material from the working keyring after generation; the subkeys remain.
If subkey management feels like too much, generate a single key (no subkeys) — it'll work, but a compromise of the laptop = compromise of the identity, with no clean recovery short of re-issue.
Generate from a wordlist. The two reasonable choices:
Don't use:
If you forget the passphrase, the key is unrecoverable. There is no reset link. The mitigation is a backup (next section).
A PGP key is two things: the secret material (the actual private key bytes) and the passphrase. You need both to use it. Lose either, and the key is dead.
A 3-2-1 backup approach for the key file:
Tools:
gpg --export-secret-keys --armor <fingerprint> produces an ASCII-armored file you can save and re-import. Encrypt it before storing — the file is already passphrase-protected (the gpg passphrase wraps it), but a second encryption layer (e.g. age, openssl, a LUKS volume) defends against weaknesses in the gpg wrapping format.paperkey (David Shaw's tool, packaged for Linux/macOS) extracts the irreducible secret material as a printable sheet of hex. You print it and store the paper. To recover: type or scan the hex back, combine with the public key file (which is published on a key server), regenerate the secret-key file. Paper survives mediums that USB sticks don't.For the passphrase: write it on paper, store separately from the key backups. Or commit it to memory if you've used a memorable diceware phrase. Never store the passphrase digitally near the key.
Always set an expiry. The reasonable range is 1 to 2 years.
Expiry doesn't mean "the key becomes permanently unusable on date X" — it means clients refuse to encrypt to or trust the key after X unless the holder publishes a new self-signature extending the expiry. gpg --edit-key <fingerprint> → expire rolls expiry forward; you re-publish the key and recipients refresh it.
Why expire if you can extend? Three reasons:
Generate a revocation certificate at the moment of key creation and store it separately from the key itself.
gpg --output revoke-<fingerprint>.asc --gen-revoke <fingerprint>This produces a signed statement saying "this key is revoked" that can be imported and published to invalidate the key — even if you've lost access to the secret material. Without the revocation cert, a lost key just expires (slowly), and an attacker who recovers your laptop has the window between compromise and expiry to misuse it.
Store the revocation cert on:
Don't store the revocation cert anywhere convenient — its only job is to be there when you need it, which is the worst day of your year.
If your key is compromised, you import the revocation cert (gpg --import revoke-<fingerprint>.asc) and publish to a key server (gpg --send-keys <fingerprint> if it was published; otherwise email correspondents directly). Within minutes, anyone refreshing the key sees it as revoked.
The minimum-viable secure key generation, end to end:
gpg --full-generate-key — ECC + Curve25519, expiry 2 years.gpg --edit-key <fingerprint> → addkey to add an encryption subkey if your client didn't auto-create one.gpg --output revoke.asc --gen-revoke <fingerprint> — generate revocation certificate, immediately.gpg --export-secret-keys --armor <fingerprint> > backup.asc — export, encrypt with age or LUKS, copy to two off-machine backup mediums.paperkey < backup.asc > backup.txt — print, store paper offsite.gpg --send-keys <fingerprint> — publish public key to keys.openpgp.org so correspondents can find it via WKD or keyserver lookup.Part 7 walks through the threat models PGP doesn't cover — endpoint compromise, metadata correlation, fingerprint verification failures, no forward secrecy, coerced disclosure. The cases where you can do everything in this part right and still get burned.