A PGP key pair is two files that stay with you for years: a public key you hand out freely, and a private key that is the only thing standing between an impersonator and your name. Making one takes about a minute. Making one you will not regret takes a little thought about four decisions, which is most of what this guide is about.
If you can run a command, run this one. GnuPG is the reference implementation of OpenPGP: it is what the ecosystem is tested against, it stores the key in a keyring the rest of your tools already know how to find, and it writes a revocation certificate for you without being asked.
gpg --full-generate-key
It asks four questions, in order: algorithm, key size, expiry, and your name and email. The next section is what to answer.
The four decisions
Algorithm
Take Curve25519 — GnuPG calls the signing half ed25519, and it is the
default in current versions. It is fast, the keys are small enough to paste into
an email, and it is not going anywhere.
Pick RSA 4096 only when something you must work with cannot read anything else. That is genuinely rare now, and it is a decision you make because a specific piece of software forced it, not because bigger sounds safer.
Expiry
Set one. Two years is a reasonable default.
An expiry date is not a deadline — it is a dead-man's switch. If you lose the laptop, forget the passphrase, or simply stop using PGP, the key retires itself instead of sitting on a keyserver forever, looking valid, inviting people to encrypt things you will never read. You can push the date back at any time as long as you hold the private key, so setting one costs you nothing.
Identity
The name and email become the key's user ID, and they are public. Use the address people will actually try to reach you at. You can add more addresses to the same key later; you do not need a key per address.
Passphrase
The private key file is not enough to be you — the passphrase is the second half. Use a long one you can type from memory, store it in your password manager, and understand that there is no recovery. Lose it and the key is gone.
Key generation is only as trustworthy as the computer doing it. A shared or
compromised machine produces a key you cannot rely on, and that is true whether
the key came from gpg, from a browser tab, or from anywhere else. This is the
one part no tool can fix for you.
Generating it with GnuPG
gpg --full-generate-key walks you through the four decisions above. If you
already know your answers, one line does the whole thing:
gpg --quick-generate-key "Ada Lovelace <[email protected]>" ed25519 default 2y
That reads: this identity, Curve25519, the default capabilities for it, expiring in two years. GnuPG prompts once for a passphrase and prints the new key's fingerprint.
Check what you got:
gpg --list-keys --keyid-format=long
pub ed25519/065CE88BAEFD1DF9 2026-09-09 [SC] [expires: 2028-09-08]
C9CC70A661424FBD029E589F065CE88BAEFD1DF9
uid [ultimate] Ada Lovelace <[email protected]>
The long hex string on the second line is the fingerprint — the only form of the key identity worth reading out loud or comparing in person. Short key IDs can be forged; fingerprints cannot.
Get the two things out
The public key is what you give people:
gpg --armor --export [email protected] > ada-public.asc
The private key is what you back up, somewhere offline:
gpg --armor --export-secret-keys [email protected] > ada-private.asc
Both are plain text, starting with -----BEGIN PGP PUBLIC KEY BLOCK----- and
-----BEGIN PGP PRIVATE KEY BLOCK----- respectively. The private one is still
encrypted with your passphrase, which is what makes writing it to a USB stick
merely uncomfortable rather than reckless.
The file most people miss
When GnuPG generated the key, it also wrote a revocation certificate without telling you much about it:
gpg: revocation certificate stored as
'/home/ada/.gnupg/openpgp-revocs.d/C9CC70A661424FBD029E589F065CE88BAEFD1DF9.rev'
That file is how you announce that a key is dead — after a stolen laptop, or a forgotten passphrase. You cannot make one later without the private key, which is precisely the situation where you will want it.
- Copy the
.revfile out of~/.gnupg/openpgp-revocs.d/to somewhere that is not the machine holding the key — a password manager attachment or an offline drive. - Copy the exported private key to the same place.
- Store the passphrase separately from both.
Anyone holding that certificate can revoke your key, so it needs the same care as the private key itself. Keep it; do not publish it.
The browser route
If installing GnuPG is not an option, the constraint is real and worth naming rather than working around: a locked-down work laptop, a borrowed machine, a phone, or a single key you need in the next five minutes.
The browser tool makes the same four decisions explicit — algorithm, expiry, identity, passphrase — generates the pair with openpgp.js inside a worker, and gives you the public key, the passphrase-protected private key and a revocation certificate. Nothing is uploaded, because there is no server-side step to upload to.
The result is an ordinary OpenPGP key. When you do get to a machine with GnuPG, it imports like any other:
gpg --import ada-private.asc
What to do next
You have a key pair; nobody can use it yet. Publish the public key where the people who write to you will look — your website, your email signature, a keyserver — and give the fingerprint out in person when it matters.
Then use it. Signing a message proves it came from you; encrypting one means only the holder of the matching private key can read it.
