What happens if an OpenPGP subkey gets compromised?

Question

In my GnuPG keyring, I have a primary key for creating keys and three subkeys: two for encryption and one for signing. All of then have the same password. If a subkey gets compromised, is it possible for the thief or whatever to revert my subkey and discover my password? That happening, I would have to change the password of my primary key, right?

Answer 1

If a subkey gets compromised, is it possible for the thief or whatever to [...] discover my password?

The passphrase is used to encrypt the private keys (both primary and subkeys) using a derived session key and symmetric encryption. The symmetric encryption algorithms used by OpenPGP are all strong considering known plain text attacks; thus when the attacker only gets hold of the unencrypted private key, he will not be able to conclude back to the session key, nor the passphrase.

That happening, I would have to change the password of my primary key, right?

Probably an attacker will rather also get hold of the passphrase. This obviously means he will be able to decrypt the other private keys in case he gets hold of a copy encrypted with this very passphrase (so without any surprises, changing the passphrase after the keys have been compromised will not bother an attacker at all, as he already has copies of the keys encrypted with the old passphrase).

So yes, changing the passphrase might be reasonable, but also make sure to verify whether the attacker might have got hold of copies of your primary key encrypted with the old passphrase. If so, consider your primary key compromised and better revoke it, either.

If a subkey gets compromised, is it possible for the thief or whatever to revert my subkey [...]?

Getting to the most relevant part of your question: subkeys can only be used for their very specific purpose, usually signing (documents, messages and code), encryption and/or authentication. Subkeys are never allowed to perform certifications (signatures on keys); this includes those on other's keys, but also on your own keys. Given the fact that all key management operations like issuing new subkeys, user IDs, changing revocation dates, revoking keys, ... includes issuing self-signatures, this means an attacker getting hold of your subkey cannot change your keys (not even revoke the subkey), he can only use the key for the purpose it was created for.

Revoking the subkey is another self-signature issued by the primary key, so even if you lost control over the subkey, you can still revoke it (given you have access to the primary key).