There are many reasons why you may want to create a new key:
- lost access to your old secret key
- lost access to the password for your key
- deprecating a key using weak security
This KB gives guidance on how to transition keys. The steps you may want to take for the transition highly differ on your individual needs - depending on threat-level, key distribution and other factors. So take this KB as recommendation and make your own assumptions on how to best transition.
1. Create a new key
The first step is to create your new key in GPG Keychain. Ensure you have the latest GPG Suite installed on your mac. The current default is to use ECC - Sign & Encrypt with a length of 256 and an expiration data in 4 years time. You can always extend keys, even when expired, as long as you have the secret key and the password. GPG Keychain will automatically create a revocation certificate which is stored on your mac. Once the new key is created, we strongly recommend exporting both secret and public key and moving the key to a secure backup location. That could e.g. be a password manager where you store the small key file or a USB-drive in a bank safe.
2. (Optionally) create a transition statement
Write a short signed document saying the old key is being replaced, listing both full fingerprints of old and new key. Sign it with both keys so each vouches for the other. Publish it on your website and email it to your regular correspondents.
3. Cross-sign the keys
Have the old key sign the new key, so your existing web of trust carries over. Then sign the old key with the new key. By doing so, you prove that you have control over both keys.
4. Distribute the new key
Upload the new key to https://keys.openpgp.org (verifies your email via a confirmation link) and/or publish via WKD on your own domain.
Add the fingerprint to your website, email signature, Codeberg/GitHub/GitLab profile, Keyoxide/Keybase-style proofs, etc.
Ask people who've signed your old key to verify and sign the new one, ideally in person or via a trusted channel.
5. Overlap period
Keep both keys valid for a while (weeks to months) so people can migrate. During this time you can still decrypt old messages with the old key, and tell correspondents to start encrypting to the new one. In GPG Keychain double click the old key and tick the Disable option to ensure only the new key is used for outgoing signed messages. You can set an expiration data on the old key to have it automatically expire. Don't rush this, as a gentle grace period allows for a smoother transition and gives your peers a chance to switch to your new key.
6. Retire the old key
Either the set expiration data hits and your old key expires or you can manually revoke your old key. Do this once the overlap period ends. Revocation is permanent. Do not delete the old key. You'll need it to decrypt old messages and archived files. Back it up securely (offline, encrypted).
7. (Optionally) update everything that references the old key
- Git commit/tag signing config
- Password managers - re-encrypt if needed
- Package signing, SSH via gpg-agent (authentication subkey), email clients, CI secrets
- Any keyring-based trust (apt repos, etc.) if you publish software
Special cases
- Old key compromised or lost: skip the overlap. Revoke immediately (using your revocation certificate), generate the new key, and notify people out-of-band. You can't produce a trustworthy cross-signature from a compromised key, so rely on other channels (website over HTTPS, social posts, mutual contacts) to establish the new key.
- Old key is weak (e.g. 1024-bit DSA): same process, but don't wait long to retire it.
- Alternative to a new key: if the old key is fine and only the subkeys are stale or weak, you can just add new subkeys and expire/revoke the old ones. That keeps your identity and signatures intact with no transition needed. Usually only a weak or compromised primary key justifies a full migration.
Congratulations - you are now using a modern and strong OpenPGP key 🙌 💪 🔐