GPG Part 2: Key Revocation

Almost immediately after posting the last article on creating, distributing, and signing GPG keys, a few good questions started flowing in over Twitter. The questions were basically about "what if I lose my secret key?"

In short: the answer is "well, you're hosed." But GPG has some other features built-in to help you out. You just need to be prepared. That usually means having a revocation certificate ready to use. I'll cover that in a moment.

If you have lost your secret key (the secret keyring file itself) for any reason, for all intents and purposes you cannot ever decrypt anything that was encrypted with your public key ever again. The secret key is almost assuredly much, much more complex than the password or passphrase that you chose to protect it. As MC Frontalot would say: "you can't hide secrets from the future with math." so when petaflop computing power comes to the desktop, you may be able to crack it in a matter of months. Until then, your data is gone. This includes any new communication sent to you from others who have your public key.

Obviously, if people are sending you encrypted data and you have no way to decrypt it, that's A Bad Thing™.

If you have simply forgotten your passphrase, and it's a simple one that's 8 characters or less, alpha-numeric with upper/lowercase and no keyboard symbols, you may be able to brute-force the password that is protecting the key. That's way beyond the scope of this post.

Enter: Key Revocation
Revoking your public key is a quick way to advertise that the key should no longer be used. This can be for many reasons. The most obvious is if you feel your secret key has been compromised. In the event that your workstation got rootkitted, your backups were stolen, or you errenously left your secret key somewhere that it could have been accessed by someone else, you can't rely on the passphrase itself to maintain absolute secrecy of your data. Remember: passphrases can be cracked much easier than the unprotected secret key itself.

When to generate a revocation certificate:
I usually generate one soon after generating my keypair, which states "I have lost the secret key" or something of that nature. If you lose the secret key or forget the password to it, it's too late to generate the revocation certificate. You need both the secret key (and thus its password) to do this.

If you fear that the key has been compromised, you should generate one at that time which states the nature of the compromise.

To generate a revocation certificate, issue "gpg --gen-revoke [keyID]" and follow the prompts.

$ gpg --gen-revoke 19A473C7

sec 1024D/19A473C7 2009-04-25 Test! (This one is getting revoked!)

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 3
Enter an optional description; end it with an empty line:
> I'm revoking this on purpose
Reason for revocation: Key is no longer used
I'm revoking this on purpose
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Test! (This one is getting revoked!) "
1024-bit DSA key, ID 19A473C7, created 2009-04-25

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
Version: GnuPG v1.4.9 (OpenBSD)
Comment: A revocation certificate should follow

This key, if it falls into the wrong hands, can be used by anyone to revoke your public key! Make sure to keep it safe. Back it up onto long-term storage that is reliable, or even print it out. It's relatively short, so it won't be too hard to type it in manually.

To use the revocation cert, simply import your public key (if it's not already in your keychain) and import the revocation cert. This will merge it with your public key and notify GPG that it's no longer valid. Then, if you have exported your public key to a keyserver, export it again as shown in part 1.
$ gpg --import testrev.txt 
gpg: key 19A473C7: "Test! (This one is getting revoked!) " revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
You should also contact those who may send you communication and let them know to refresh your key from the keyserver. Until they do so, their installation of GPG (or other OpenPGP compliant software) will not know your public key has been revoked.

Of course, it's best to avoid the need to revoke certificates in the first place!
  • Keep your secret key in a safe place, such as on your workstation, not a file-server or a shared host.
  • Keep UNIX permissions at 600 (rw- --- ---) or otherwise make sure your account is the only one that can access the keyrings and/or any exported secret keys.
  • Back up your keys to long-term media (CD-RW is usually fine) and keep it in a place that's safe from attackers and environmental harm (a cool, dark, dry place like a fire safe).
  • For crying out loud, remember your passphrases without making them short and/or easy to guess. Example: use a favorite quote or passage written in l33t. Preferably a passage that few people know you like. Using your email signature line? Bad idea.

blog comments powered by Disqus