Keeping a GPG primary key offline

A GPG identity is only as safe as its primary key. Whoever holds it can create new subkeys, extend expiry dates, add user IDs and sign other people’s keys — everything needed to impersonate you indefinitely. Yet for day-to-day Git signing, the primary is never used: a signing subkey does the work. Keeping the primary on the laptop therefore buys no convenience and exposes the one key whose loss is unrecoverable. This page moves it offline and documents the brief, infrequent procedure for using it. It assumes the subkey layout from setting up GPG commit signing with subkeys and is part of protecting and rotating signing keys.

When to use this approach

  • You sign with GPG and your primary key’s secret part is currently on an everyday machine.
  • Your key is published, cross-signed, or trusted by a release process, so replacing it would be disruptive.
  • You can tolerate a short manual step once or twice a year for rotation and expiry extension.
  • If your key is personal, unpublished and trivially replaceable, the effort may not be worth it; SSH signing with per-device keys is simpler, as in using a separate signing key per device.

Step 1 — Confirm the layout before moving anything

You need a certify-only primary and at least one signing subkey. If the primary also has the sign capability and Git is pointed at it, fix that first, or removing the primary will break signing.

gpg --list-secret-keys --keyid-format long --with-subkey-fingerprints
# sec   ed25519/0xA1B2C3D4E5F60718 [C]          <- certify only: good
# ssb   ed25519/0x1122334455667788 [S]          <- signing subkey: good
git config --get user.signingKey                 # must be the [S] subkey, with !

Step 2 — Export everything to offline storage

Export the full secret key, the public key and a revocation certificate. These three files are the recovery kit. Write them to encrypted removable media — two copies, stored separately.

FPR=A1B2C3D4E5F60718...   # full primary fingerprint
umask 077
mkdir -p /media/offline/gpg-$(date +%F)
cd /media/offline/gpg-$(date +%F)
gpg --armor --export-secret-keys "$FPR" > secret-primary-and-subkeys.asc
gpg --armor --export "$FPR"            > public.asc
gpg --output revoke.asc --gen-revoke "$FPR"
sha256sum *.asc > SHA256SUMS
The offline recovery kitThree files make up the kit: the full secret export, which can recreate the identity; the public key, for re-publishing; and a revocation certificate, which can kill the identity even if the secret export is lost. Two copies are stored in different places.Full secret exportprimary + subkeysrestores everythingPublic keyre-publish anywhereRevocation certworks withoutthe secret keystore two copies apart — a single drive in a drawer is one failure away from nothing 
# Verification: the export restores into an empty keyring
GNUPGHOME=$(mktemp -d) sh -c 'gpg --import secret-primary-and-subkeys.asc && gpg -K --keyid-format long'

Do not skip that verification. The next step deletes the primary from the laptop, and an untested backup is not a backup.

Step 3 — Remove the primary secret from the laptop

GnuPG has no single command to delete only the primary’s secret part, so the standard method is to delete all secret keys for the identity and re-import only the subkeys.

gpg --armor --export-secret-subkeys "$FPR" > /tmp/subkeys.asc
gpg --delete-secret-keys "$FPR"          # confirms interactively — read the prompt
gpg --import /tmp/subkeys.asc
shred -u /tmp/subkeys.asc
gpg --list-secret-keys --keyid-format long
# sec#  ed25519/0xA1B2C3D4E5F60718 [C]     <- '#' means the secret part is absent

⚠️ SAFETY WARNING: gpg --delete-secret-keys permanently removes secret material from this keyring. Run it only after Step 2’s restore test passed. If you delete with a broken backup, the identity cannot be recovered: you would have to revoke it with the revocation certificate (if that copy works) and start again. Keep the media mounted until you have confirmed the sec# output and a successful test commit.

# Verification: signing still works with only the subkey present
git commit --allow-empty -m "post-offline signing test" && git log -1 --format='%G? %GK'
What a stolen laptop can do, before and afterWith the primary on the laptop, a thief can sign commits, mint new subkeys, extend expiry and certify other keys as you. With only the signing subkey present, they can sign until you revoke that one subkey, and nothing else.Primary on laptopSubkey onlysign commitsyesuntil subkey revokedcreate new subkeysyesnoextend expiryyesnocertify other keysyesnothe attacker gets one revocable subkey instead of your whole identity

Step 4 — Use the primary when you need it, then put it away

You need the primary to add or revoke subkeys, extend expiry, add a user ID or certify someone else’s key. Do it in a throwaway keyring, ideally on a machine that is offline for the duration.

The rare certification ceremonyMount the offline media, import the full key into a temporary keyring, perform the certification task, export the updated public key and new subkeys, then destroy the temporary keyring and unmount. The everyday laptop never holds the primary.Mount offline mediaverify SHA256SUMSTemporary keyringimport full secretCertify or rotateextend, add, revokeExport and destroypublic + subkeys outdone once or twice a year, it takes ten minutes 
export GNUPGHOME=$(mktemp -d)
gpg --import /media/offline/gpg-*/secret-primary-and-subkeys.asc
gpg --quick-set-expire "$FPR" 2y                       # extend the primary
gpg --quick-add-key "$FPR" ed25519 sign 1y             # add next year's subkey
gpg --armor --export "$FPR" > public-updated.asc
gpg --armor --export-secret-subkeys "$FPR" > subkeys-updated.asc
gpg --armor --export-secret-keys "$FPR" > /media/offline/gpg-$(date +%F)-secret.asc
rm -rf "$GNUPGHOME"; unset GNUPGHOME

Then, on the laptop, import subkeys-updated.asc, point user.signingKey at the new subkey, and upload public-updated.asc to your forge.

Step 5 — Write the procedure down where you will find it

The ceremony happens so rarely that nobody remembers it. Keep a one-page note with the offline media: what the files are, the fingerprint, the commands above, and where the second copy is. Put a calendar reminder a month before the subkey expires, as described in setting expiry and renewal reminders for signing keys.

Validation checklist

Frequently Asked Questions

Can I use a hardware key instead of offline media?

Yes. Moving the subkeys to a hardware token and keeping the primary on offline media is the strongest common setup. Some people also keep the primary on a second token, which avoids storing a file but makes the backup a device rather than a document.

What if I lose both offline copies?

The primary is gone, but signing with existing subkeys continues until they expire. Use that time to create a new identity and publish the revocation certificate for the old one, if you still have it. This is why the revocation certificate is worth storing in more places than the secret key.

Does the forge need the primary key to verify signatures?

No. The forge needs only the public key, which contains the primary’s public part and the subkeys. Verification never touches any secret material.