3

I have seen from different sources that the sole purpose of the master key should really be to generate the subkeys, and that it should be subsequently backed up to an offline location and deleted from the device on which it was generated. Why is that? I just don't get the rationale for having both master and subkeys since, ultimately, they're all associated with the same passphrase.

Jens Erat
  • 24,566
  • 12
  • 82
  • 103
Tfovid
  • 131
  • 2
  • It is good cryptographic principle to use keys only for one purpose, this way you can separate signing from decryption and certification. It also alllows to roll over decryption keys without the need of reevaluating the Web of tust. However this can also be done with main keys (and in fact most automated users of PGP seem to not care about subkeys) – eckes Nov 23 '17 at 22:13

2 Answers2

2

The primary key, and only the primary key is allowed to perform key management operations (adding and removing user IDs, subkeys, ...) and issue certifications on other keys. Storing the secret primary key offline provides additional security against misuse of those especially sensitive operations.

Furthermore, the primary key is target of incoming certifications from other keys. If you have to revoke a subkey because it got compromised (computer got hacked, issues like the DSA and random number generator bug Debian had), you roll over your subkey and everything's fine (at least, for messages encrypted/signed in future). All your contacts have to do is fetching the updated key from the keyservers running gpg --recv-keys <key-id>. If you have to revoke your primary key instead, you lose all certifications on that key: all trust in that key is lost, you will have to start over distributing your key and getting it signed.

Jens Erat
  • 24,566
  • 12
  • 82
  • 103
  • Thanks. I understand that the primary key has more of an "admin" function in that regard. But what I don't understand is that both primary and subkeys are ultimately tied to the same passphrase. The whole reasoning whereby a primary key can conveniently revoke a subkey if it ever gets compromised is therefore somewhat a "logical fallacy". If I lose a copy of my car key, my car isn't any safer from theft if I happen to have a "primary" key backed up somewhere... What part am I missing here? – Tfovid Aug 28 '17 at 15:29
  • The main idea is not to expose the primary secret key at all, thus keeping it offline (eg. in an additional copy of your keyring on a thumb drive, another computer, ...) when not needed. Even if an attacker gets hold of your subkeys and your passphrase, he still has no access to the private key and you could just rollover subkeys (setting up a new passphrase might also be a good thing in this case). Your primary secret key was never affected and thus can stay unchanged. – Jens Erat Aug 28 '17 at 20:46
  • @Tfovid The best practices of subkey is documented here: https://wiki.debian.org/Subkeys. In Section 'How' step 5, it talks about moving primary key/pair to offline keystore, e.g., USB, deleting it from active keystore and then changing the passphrase so that the passphrases of the offline (primary) and active (subkey) keystore are different. – nethsix Aug 13 '23 at 05:43
0

Simple example

Nowadays you use one password (possibly autogenerated) per website: more and more tools like KeepassXC and browsers like Firefox let you organize your passwords.

Why we do that?

Because this is a good security practice: a security breach in one website does not propagate to other websites.

What's the link with GPG subkeys?

The parallel is simple: you have a "trust context" between you and a website: the trust is by design, limited to one and one use only, as the password is valid on that website only.

You can achieve the same with subkeys: you have a trust context between you and something that requires a GPG key. You want to limit the context in which the subkey is used the same way you limit the context of the website passwords.

That GPG key may be used in a software (eg. Thunderbird), on a remote website (eg. Launchpad), a remote machine (automated signature of backups). In each of those contexts, you want to limit the scope of that context as much as possible. You would not be happy that the GPG key you are using in a remote machine gets hacked and then be used for signing Debian packages on your behalf on LaunchPad. You use subkeys for that.

It is not perfect as each subkeys still carries your digital identity until it get revoked, but it limits a bit a type of security breaches.

Something I tried to explain in my blog in more details.

Raffi
  • 101
  • 1
  • It's not risk-free though, like you put your whole eggs to one basket... – Sir Muffington Nov 05 '23 at 13:59
  • If one of your secret is leaked, it is usually not a good thing. But as you do for a website (you go and change your password), here you revoke the compromised subkey and replace it with a new one. If a "password" has been used in between for various things on a website, then your identity has been compromised during that laps of time on that website. Same is for a subkey. But both type of problems does not force you to start completely with a new identity, only specific contexts. – Raffi Nov 06 '23 at 15:39
  • 1
    I meant the master password of your password vault.. – Sir Muffington Nov 06 '23 at 18:49