Revoking a PGP key: revocation certificates and GnuPG

Revoking adds a special signature, a key revocation signature, to your public key. Once other people import the updated key, their software will no longer encrypt to it and will show signatures made with it as coming from a revoked key. Nothing is deleted. The revocation travels with the key, the same way new signatures do.

A revocation cannot be taken back. As the note GnuPG writes into every certificate says, “It is not possible to retract such a revocation certificate once it has been published.”

• Delete (gpg --delete-secret-and-public-key) only removes the key from your own computer. Copies elsewhere stay valid.
• Expiry is a date set on your key. You can move it later with gpg --quick-set-expire as long as you still have the private key. It is a safety net: if you lose everything, the key at least stops working on its own.
• Revocation is permanent and public. Use it when the key is compromised, replaced or no longer used.

It is a revocation signature made in advance and kept apart from your key. The private key and passphrase are needed only to make it. Anyone who has the file can later revoke your key, but they cannot read your mail or sign in your name with it.

Almost certainly, if you made your key with a current GnuPG. When it creates a key, it prints a line like this:

gpg: revocation certificate stored as '/home/you/.gnupg/openpgp-revocs.d/C9D3642643533F47C090431DF2C9F13D0062B815.rev'

The directory ~/.gnupg/openpgp-revocs.d/ holds one file per key, named after the key’s fingerprint. The GnuPG manual tells you to back these files up, and to move them to external storage if you keep your primary private key off the computer. A certificate made this way records the reason “no reason specified”, which is fine for emergencies.

Use --gen-revoke (its newer name is --generate-revocation). It needs your private key and passphrase:

gpg --output revoke-superseded.asc --gen-revoke C9D3642643533F47C090431DF2C9F13D0062B815

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 2
Enter an optional description; end it with an empty line:
> Replaced by my new key, see my website
>
Reason for revocation: Key is superseded
Replaced by my new key, see my website
Is this okay? (y/N) y
ASCII armored output forced.
Revocation certificate created.

The reason matters. Under RFC 9580, “key material has been compromised” makes every signature from that key suspect, even old ones. “Superseded” and “retired” leave signatures made before the revocation valid. Note that GnuPG’s menu numbers are not the code numbers in the standard: in the standard, compromised is 2 and superseded is 1. The program writes the right code for you.

Somewhere offline and separate from your key backup: a USB stick in a drawer, or a printout. The armored text is short enough to type back in if you have to. GnuPG itself suggests printing it, but warns that the print system of your machine might keep a copy. If someone steals the certificate, the worst they can do is revoke your key early. That is a nuisance, not a breach.

1. If you still have the private key, make a fresh certificate with reason 1, “Key has been compromised”. If not, use the stored one.
2. Import it and publish the revoked key (see below).
3. Create a new key and tell your contacts its fingerprint through a channel they trust.

A strong passphrase buys you time, because the thief needs both the key file and the passphrase. It does not make revoking optional.

You cannot make a new revocation certificate, because that needs the private key unlocked with the passphrase. You can still use the certificate GnuPG stored in openpgp-revocs.d when you created the key, or any copy you made. It was signed back then and needs no passphrase now. Then make a new key.

Then nobody can revoke the key, and there is no back door. What you can do:

• Wait for the key to expire, if it has an expiry date. This is the best argument for always setting one.
• On keys.openpgp.org, remove your email address from the old key with the manage page. It proves you own the address by email and does not need the key.
• Publish your new key and tell people directly that the old one is dead.

In the PGP 2.x days, people edited a user ID to read “key invalid”. That never worked well. Anyone can add an unsigned user ID to a copy of a key, so it proves nothing, and keys.openpgp.org does not publish an address until its owner verifies it.

Yes, once your contacts have the new one. Choose “Key is superseded”, so that your old signatures stay valid. Many people first sign the new key with the old one, so contacts who trusted the old key have a reason to trust the new one.

GnuPG puts a colon in front of the -----BEGIN PGP PUBLIC KEY BLOCK----- line, so you cannot import the file by accident. If you try, you get gpg: no valid OpenPGP data found. Remove the colon first. This command writes a fixed copy and leaves the original untouched:

sed 's/^:-----BEGIN/-----BEGIN/' ~/.gnupg/openpgp-revocs.d/C9D3642643533F47C090431DF2C9F13D0062B815.rev > revoke.asc
gpg --import revoke.asc

gpg: key F2C9F13D0062B815: "Test User <test@example.org>" revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1

gpg --list-keys now shows [revoked: …] on the key and [ revoked] on its user IDs. Revoking a key on your own keyring has no effect on anyone else until you publish it.

Send the revoked public key everywhere people get your key:

gpg --keyserver hkps://keys.openpgp.org --send-keys C9D3642643533F47C090431DF2C9F13D0062B815

keys.openpgp.org passes on revocations and other non-identity data without email verification. Since GnuPG 2.5.3 there is no default keyserver, so give one with --keyserver or set it in dirmngr.conf. If you publish your key through a Web Key Directory or on your website, replace that copy too. Send the file to regular contacts. Their copy updates when they run gpg --refresh-keys, or when they import your file.

Yes. To revoke a subkey, for example a lost encryption subkey on a smartcard:

gpg --edit-key C9D3642643533F47C090431DF2C9F13D0062B815
gpg> key 1
gpg> revkey
gpg> save

To revoke an old address but keep the key:

gpg --quick-revoke-uid C9D3642643533F47C090431DF2C9F13D0062B815 "Test User <old@example.org>"

You cannot revoke the last remaining user ID this way. Publish the updated key as above. The GNU Privacy Handbook explains why this works: revoking parts of a key adds revocation signatures instead of deleting anything, so the change reaches others when they merge your updated key.

GnuPG still has addrevoker in gpg --edit-key, which names another key as a “designated revoker”. RFC 9580 deprecates that mechanism. It says applications must not generate it, because enforcement is uneven. It recommends a simpler approach: make a revocation certificate and give it to a person you trust to hold in escrow. That person can publish it if you are unable to, and nothing in your public key shows who it is.