My OpenPGP private keys are set up with sub-keys. What happens if I revoke a sub-key and re-issue a new one?

Question

I have set up my OpenPGP keys with sub-keys, following the general instructions laid out in "Creating the perfect GPG keypair." The general gist is that you create a "master keypair" which is not stored on your laptop, but instead on a secure air-gapped device. In my case, it's an encrypted USB key. I also have a paperkey version, and printed revocation keys for the master key, in case the digital version is lost or corrupted. My laptop only has subkeys, not the master signing key. As a result, when you run gpg -K (to display secret keys), you get:

/Users/myusername/.gnupg/secring.gpg
-------------------------------
sec#  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <[email protected]>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

The sec# indicates that the master signing key is not stored on the computer. If I load up my encrypted USB key and then run gpg gpg --home=/path/to/secure/gpg/keys/.gnupg -K, it would show:

/path/to/secure/gpg/keys/.gnupg/secring.gpg
-------------------------------
sec  4096R/0x123412341234FFFF 2014-04-18
uid                            My Name <[email protected]>
ssb   4096R/0x123412341234AAAA 2014-04-18
ssb   4096R/0x123412341234BBBB 2014-09-24
ssb   4096R/0x123412341234CCCC 2014-09-30

As you see, it shows sec, not sec#.

Under this setup, if your laptop is compromised, you can revoke the subkeys safely without losing any connection with the web of trust - because you are connected to the web of trust through your master signing key.

---

Let's say that my laptop is compromised, which this model supposedly protects against. The best practice, I think, would be to:

1. Go get my secure USB key, and load up GnuPG from the secure keyring
2. Using the master keypair, I would revoke my sub-keys [because they are now compromised]
3. Now, I would issue new sub-keys for signing and encrypting, and push all of these changes to public keyservers.

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GnuPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

Am I right in this at all? Can someone please clarify?

Answer 1

My question is: Is this the right thing to do? What happens here exactly, when you do this? I presume that it generates a new private key/public key pair, and invalidates the old one. That way, if an adversary has my old private keys - they can in theory access old communications encrypted to my old public key. But they could not sign anything as me, because that private key will have been revoked. Further, when someone looks me up through a keyserver, both the old and new public keys will be visible, but the old public key will be shown as revoked and the new one will have a newer date, so a GPG user trying to send me an encrypted message or encrypted file will automatically encrypt it to the new (non-revoked) public key. And the adversary will be unable to read this message.

You pretty much got everything right; that's exactly what subkeys are primarily used for (there are some other neat use cases apart from exchanging subkeys without losing reputation in the web of trust).

I'd add that there might be a given latency: the key needs some time (usually minutes, less than an hour) to spread through-out the key server network. If the situation is critical, and you know somebody is listening your communication, consider uploading to different servers in the SKS server pool to speed up reconciliation/spreading of the key.

Furthermore, your communication partners will very likely only occasionally fetch updates of your key. Consider sending an information about changed subkeys due to compromised old ones; and also explain why your master key is still save.