Recipe 7.22 Revoking a Key

7.22.1 Problem

You want to inform a keyserver that a particular public key (of yours) is no longer valid.

7.22.2 Solution

  1. Create a revocation certificate:

    $ gpg --gen-revoke --output certificate.asc key_id
  2. Import the certificate:

    $ gpg --import certificate.asc
  3. Revoke the key at the keyserver:

    $ gpg --keyserver server_name --send-keys key_id
  4. Delete the key (optional)

    $ gpg --delete-secret-and-public-key key_id

THINK CAREFULLY BEFORE DELETING A KEY. Once you delete a key, any files that remain encrypted with this key CANNOT BE DECRYPTED. EVER.

7.22.3 Discussion

At times it becomes necessary to stop using a particular key. For example:

  • Your private key has been lost.

  • Your private key has been stolen, or you suspect it may have been.

  • You have forgotten your private key passphrase.

  • You replace your keys periodically (say, every two years) to enhance security, and this key has expired.

Whatever the reason, it's time to inform others to stop using the corresponding public key to communicate with you. Otherwise, if the key is lost, you might receive encrypted messages that you can no longer decrypt. Worse, if the key has been stolen or compromised, the thief can read messages encrypted for you.

To tell the world to cease using your key, distribute a revocation certificate for that key: a cryptographically secure digital object that says, "Hey, don't use this public key anymore!" Once you create the certificate, send it directly to your communication partners or to a keyserver [Recipe 7.19] for general distribution.

For security reasons, the revocation certificate is digitally signed by you, or more specifically, with the private key that it revokes. This proves (cryptographically speaking) that the person who generated the certificate (you) is actually authorized to make this decision.

But wait: how can you create and sign a revocation certificate if you've lost the original private key necessary for signing it? Well, you can't.[3] Instead, you should create the certificate in advance, just in case you ever lose the key. As standard practice, you should create a revocation certificate immediately each time you generate a new key. [Recipe 7.6]

[3] And this is a good thing. Otherwise, anybody could create a revocation certificate for your keys.

Guard your revocation certificate as carefully as your private key. If a thief obtains it, he can publish it (anonymously) and immediately invalidate your keys, causing you a big headache.

7.22.4 See Also and

    Chapter 9. Testing and Monitoring