GPG Key Marked: Managing a Revoked Personal Key

When a GPG personal key is revoked, it is cryptographically marked as invalid but remains in your local keyring. To resolve this, you must first verify the revocation status using gpg --list-keys, then generate a fresh key pair with gpg --full-generate-key, and finally update your public keyserver or distribution channels so contacts can retrieve the new valid identity.

Understanding Key Revocation Status

A revoked GPG key does not disappear from your system automatically. Instead, its status changes to indicate that it should no longer be used for encryption or signing. This state is typically triggered when you suspect the private key has been compromised, lost, or when you simply wish to retire an old identity. The primary indicator of this state is visible when you inspect your keys via the command line. When you run gpg --list-keys, look for the r flag next to the key ID. For example, a line might appear as:

sub   rsa4096 2023-01-01 [R]
uid           [ revoked] John Doe <[email protected]>

The [revoked] tag on the user ID and the R flag on the subkey confirm that the cryptographic trust associated with this specific key has been explicitly withdrawn. It is crucial to understand that this revocation is a local declaration unless you have previously uploaded a revocation certificate to a keyserver. If you only revoke locally, other users will still see the key as valid until they download your updated revocation signature. For more details on managing missing or inaccessible keys, consider reviewing our guide on GPG Could Not Find Key Listed - How to Fix. This often helps distinguish between a truly missing key and one that is merely revoked or hidden due to configuration errors.

Generating a New GPG Key Pair

Once you have confirmed the old key is revoked, the immediate next step is to create a new identity. Modern versions of GnuPG recommend using the full generation wizard to ensure best practices are followed regarding algorithm selection and key size. Execute the following command to start the process:

gpg --full-generate-key

You will be prompted to select the type of key. RSA is widely supported, though EdDSA (specifically ed25519) is increasingly preferred for its speed and security profile. Select the algorithm that matches your needs. Next, choose the key length; for RSA, 4096 bits is the standard recommendation for long-term security, while 2048 bits is considered the minimum acceptable limit. After selecting the algorithm and size, set the expiration date. A common practice is to set a reasonable expiration period, such as two years, rather than "never." This encourages regular key rotation and reduces the impact if a key is compromised later. Finally, provide your real name, email address, and an optional comment. Confirm the information by typing O (for Yes). You will then be asked to enter a passphrase to protect the newly generated private key. Ensure this passphrase is strong and unique, as it is the sole barrier against unauthorized use of your private key.

Distributing Your New Public Key

Creating the key is only half the battle; you must make the new public key available to others. If you do not distribute the new key, your contacts cannot encrypt messages to you or verify signatures made with your new identity. The most robust method is to upload your new public key to a keyserver like keys.openpgp.org. Use the following command, replacing KEYID with the actual ID shown in your --list-keys output:

gpg --keyserver keys.openpgp.org --send-keys KEYID

If you are using GitHub for SSH or code signing, you may need to add the new public key to your account settings. This ensures that any automated systems or collaborators relying on your GitHub identity can validate your new credentials. For guidance on integrating GPG keys with host authentication, see Specify GPG Key Identity for SSH Host Authentication: A Tech Support Guide. Additionally, inform your direct contacts manually if necessary. Send them your new public key file (exported via gpg --armor --export KEYID > newkey.asc) so they can import it into their local keyrings. This manual step is vital for maintaining trust chains in small teams or closed networks where automatic keyserver synchronization is not enabled.

Cleaning Up Old Keys

While you can leave the revoked key in your keyring for historical reference, some users prefer to remove it to keep their workspace clean. Be aware that deleting the secret key means you can never sign anything with it again. To remove the public key entry, use:

gpg --delete-keys KEYID

To remove the corresponding private key, use:

gpg --delete-secret-and-public-key KEYID

Always double-check the key ID before executing deletion commands, as this action is irreversible. Keeping a backup of your old private key in a secure, offline location is recommended in case you ever need to decrypt old data or prove past authorship.

Frequently Asked Questions

Can I recover a revoked GPG key?

No, once a key is revoked, its validity is permanently negated in the web of trust. You cannot reverse the revocation signature without creating a new key. However, you can retain the old private key to decrypt previously encrypted messages, provided you did not delete it from your system.

Why do I still see my revoked key in gpg --list-keys?

GPG keeps revoked keys in your local keyring by default to maintain history and allow you to access old data. The r flag indicates its status, but the entry remains until you manually delete it using --delete-keys.

How do I know if someone else has downloaded my revocation?

You can check the status on the keyserver website or use gpg --refresh-keys to pull the latest updates from configured servers. If your key shows as revoked after refreshing, the network has accepted your revocation certificate.

Should I use RSA or EdDSA for my new key?

EdDSA (ed25519) is generally recommended for new keys because it is faster and uses shorter key lengths for equivalent security. However, RSA remains necessary if you need compatibility with very old software or specific enterprise environments that do not yet support EdDSA.

What happens if I lose my passphrase for the new key?

If you lose the passphrase, the key is effectively lost forever. There is no backdoor or recovery mechanism in GPG. This is why storing backups of your private key files and passphrases in secure, offline locations is critical during the initial setup.