Back up, move, renew and revoke your OpenPGP key with GnuPG

Updated November 2026

A key you cannot restore is a key you will lose. Make one offline backup of your secret key and its revocation certificate today, keep it somewhere safe, and you can survive a dead laptop, move to a new computer, renew an expiring key, or kill a stolen key.

The commands below work with GnuPG 2.2 and later, including the current stable 2.5 series (2.5.24 as of November 2026); we tested them with the GnuPG 2.4.7 package that Debian 13 ships. Upstream, the 2.4 branch reached end of life on 2026-06-30, though distributions may keep patching their own packages. Replace FPR with your key’s full 40-character fingerprint, which gpg -K prints under each sec line.

What you need to keep

Your public key does not need a special backup. It is part of the secret key export, and you have probably published it anyway.

Export a full backup

# Secret key with all subkeys, in GnuPG's backup format
gpg --export-options backup --armor --output secret-FPR.asc --export-secret-keys FPR

# Public key (handy for paperkey and for checking the backup)
gpg --export-options backup --armor --output public-FPR.asc --export FPR

# Trust values you have assigned to keys
gpg --export-ownertrust > ownertrust.txt

GnuPG asks for your passphrase during the export. The first line of the secret file is -----BEGIN PGP PRIVATE KEY BLOCK-----. The GnuPG manual describes the backup export option as including “all data which is needed to restore the key or keys later with GnuPG”. It also warns that exporting a secret key “can be a security risk if the exported keys are sent over an insecure channel”. So never email the file to yourself or upload it to cloud storage.

Where to keep it:

A paper backup with paperkey

USB sticks fail after some years. Paper lasts. The paperkey tool prints only the secret parts of a key, which makes the printout much shorter than an armored export. It does no cryptography of its own, so the passphrase protection of your key stays on the paper copy. On Debian and Ubuntu it is in the paperkey package.

sudo apt install paperkey
gpg --export-secret-keys FPR | paperkey --output key-on-paper.txt
# print key-on-paper.txt, then delete the file securely

To restore, you type (or scan) the text back in and combine it with your public key:

paperkey --pubring public-FPR.gpg --secrets key-on-paper.txt --output secret-FPR.gpg
gpg --import secret-FPR.gpg

The --pubring file must be the binary public key (gpg --export FPR > public-FPR.gpg). The paperkey author recommends testing a restore before you file the paper away.

Test the backup

Test the restore in a throw-away GnuPG home folder, so nothing touches your real keyring:

mkdir -m 700 /tmp/gpgtest
GNUPGHOME=/tmp/gpgtest gpg --import-options restore --import secret-FPR.asc
GNUPGHOME=/tmp/gpgtest gpg -K
GNUPGHOME=/tmp/gpgtest gpgconf --kill all
rm -rf /tmp/gpgtest

A working backup shows secret key imported during the import and a sec line (not sec#) for the primary key in the listing. If you see sec#, the primary secret key is missing from the backup. Use /tmp or another short path for the test folder; a very long folder path can stop gpg-agent from starting.

Move your key to a new computer

  1. Install GnuPG on the new computer (install guide).
  2. Copy secret-FPR.asc and ownertrust.txt over a safe channel: a USB stick you control, or scp between your own machines.
  3. Import and restore trust: 
    gpg --import-options restore --import secret-FPR.asc
gpg --import-ownertrust < ownertrust.txt
  4. Check with gpg -K. Your own user ID should show [ultimate]. If it shows [ unknown], you skipped the ownertrust step; run gpg --edit-key FPR, type trust, choose 5 (ultimate), then quit.
  5. Copy ~/.gnupg/openpgp-revocs.d/ and any config files you changed (gpg.conf, gpg-agent.conf).
  6. Delete the copied export files from the new machine’s disk once the import works.

Copying the whole ~/.gnupg folder between two machines with the same GnuPG version also works, but the export/import route is cleaner and works across versions and operating systems.

Extend an expiry date

An expiry date is a safety net, not a deadline you must meet with a new key. As long as you still have the secret key, you can move the date forward at any time, even after it has passed:

# Primary key: expire 2 years from today
gpg --quick-set-expire FPR 2y

# All valid subkeys as well
gpg --quick-set-expire FPR 2y '*'

gpg --list-keys FPR

With two arguments the command changes the primary key; with '*' as the third argument it changes all subkeys that are not revoked or already expired. You can also give subkey fingerprints instead of '*', and 0 removes the expiry.

Then publish the updated key so others see the new date. Other people must refresh their copy:

gpg --export your@example.org | curl -T - https://keys.openpgp.org
# others then run:
gpg --refresh-keys

If you publish through a Web Key Directory, export the key again into your WKD folder. A common mistake is to extend the date locally and forget to publish: everyone else still sees the old date and gets an “expired key” error.

Your revocation certificate

When you create a key, GnuPG 2.1 and later stores a revocation certificate automatically in ~/.gnupg/openpgp-revocs.d/, in a file named after the fingerprint with the extension .rev. The GnuPG manual warns: “Anyone who can access these files is able to revoke the corresponding key.” Back the folder up and keep that backup locked away.

The file contains an explanation and then the certificate. To stop accidents, GnuPG puts a colon in front of the first line:

:-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: This is a revocation certificate

You must remove that colon before the certificate can be used.

You can also create a fresh certificate with a stated reason while you still have the secret key:

gpg --output revoke-FPR.asc --generate-revocation FPR

GnuPG asks “Create a revocation certificate for this key? (y/N)”, then for a reason: 0 = No reason specified, 1 = Key has been compromised, 2 = Key is superseded, 3 = Key is no longer used. Pick the reason that will be true when you use it; for a stored, just-in-case certificate, “compromised” is the safe choice.

Revoke a key

No undo. A published revocation cannot be withdrawn. Once others have it, the key is dead for good. Make sure you are revoking the right fingerprint.

  1. Prepare the certificate. Either take the stored one and remove the leading colon: 
    sed 's/^:-----BEGIN/-----BEGIN/' ~/.gnupg/openpgp-revocs.d/FPR.rev > revoke-FPR.asc
    or create a new one with --generate-revocation as shown above.
  2. Import it into your own keyring. This applies the revocation: 
    gpg --import revoke-FPR.asc
    GnuPG reports revocation certificate imported and new key revocations: 1; gpg -k FPR now shows [revoked: …].
  3. Publish the revoked key the same way you published the key: upload it to the keyservers you use, replace the file in your WKD, and send it to people you write to often. 
    gpg --export FPR | curl -T - https://keys.openpgp.org
  4. Create a new key (create a key) and tell your contacts the new fingerprint.

keys.openpgp.org notes that refreshing keys with gpg --refresh-keys also fetches new revocation certificates, so people who refresh will see that the key is revoked.

Revoke only a subkey or a user ID

If only a laptop with your subkeys was stolen but your primary key is safe offline, revoke just the subkeys and add new ones. Your fingerprint, and the trust others have placed in it, stays the same:

gpg --edit-key FPR
gpg> key 1        # select the first subkey (repeat for others)
gpg> revkey
gpg> save

gpg --quick-add-key FPR ed25519 sign 2y
gpg --quick-add-key FPR cv25519 encr 2y

To retire an old email address, revoke that user ID: gpg --quick-revoke-uid FPR 'Old Name <old@example.org>'. Publish the key again afterwards.

Common mistakes

More background on revocation is in the FAQ: Key revocation.

Sources