Should I create separate GPG key pairs or just one GPG key pair for multiple uses (e.g. email, sign commits)?
Would it be better to create a GPG key pair for each use case or is it considered best practice to create just on GPG key pair for multiple use cases?
Here are my reasons for using GPG keys:
- to sign emails
- to encrypt emails
- to sign commits
- to use it with pass
Depends on what protection you think the key deserves. What I mean is: if a key would have several usages with wildly different security requirements, then it should be two different keys.
For example, if it encrypts your financial data (wallet.dat?) and needs to be closely guarded, but at the same time it encrypts your idle chat emails and needs to be copied to every single desktop/laptop/phone that you own – those should be separate keys.
Other similar examples would be having a separate keypair for business correspondence (e.g. if forced to give it up for legal reasons), a separate keypair for anything that involves automated cronjobs (e.g. a software developer's machine automatically signing nightly software releases), and so on.
Note that signing and encryption always use separate subkeys in PGP, so it is easy to import a "partial" key on this boundary. For example, you can have a device which holds only the encryption subkey and is able to read your encrypted data, while still being unable to sign anything on your behalf.
Additionally, the PGP software recognizes "signing files/messages" and "signing PGP keys" as two distinct purposes and easily allows you to have separate subkeys for them. (More precisely, the primary/root key is always used to sign other people's PGP keys, but a subkey can be used to sign general data.) This means you can have a device which can sign commits and email messages, but remains unable to sign PGP keys.
(The latter is important, because it's not just being able to sign other people's keys – although this is still something that ought to be highly protected – but also being able to sign updates to your own key, e.g. changing expiration date, adding new email addresses or even photo IDs, or even revoking the key.)
However, all subkeys under the same primary key receive roughly the same "trust" externally. For example, you can't usefully have two encryption subkeys for different specific purposes, eventually they will get mixed up. So in situations where you need to separate them by purpose (e.g. personal vs work), you would need two entirely separate PGP keys.
(Subkeys are mostly useful for key rotation, e.g. a new encryption subkey every year, or two signing subkeys using different algorithms – I still use an RSA4096 key for compatibility with old RSA-only systems, but have an Ed25519 signing subkey to make the Git commit signatures much smaller than they would be with RSA.)
I'm not expert on PGP, but I put to you that, unless you have different unconnected systems and roles, using a single key would seem better.
Particularly if you get other people to sign your keys, it is easier to prove your identity if there is a single key, and if there is an issue, there is only 1 key to be repudiated.
You might want to look at having subkeys - this will allow you to revoke some keys individually, but still maintaining 1 primary key - which could allow you to have slightly laxer security around some sub-keys then others (have a read of https://wiki.debian.org/Subkeys)
Its a bit old (but the logic does not change), https://security.stackexchange.com/questions/29851/how-many-openpgp-keys-should-i-make asks a similar question, and comes to the same conclusion that I did.