3

Say I have several different email accounts and I want to use a different encryption key for each of them but still have them all certified under one identity. Is this a good idea and how would I do it?

For example:

Jon Doe (identity; key stored on encrypted external drive) certifies

  1. jon@doe.me (personal conversations only; key stored on trusted Linux machine)
  2. jon.doe@developers.org (conversations with random people; key stored on potentially unsafe Windows machine) and
  3. jon.doe@company.com (business conversations; key stored on Windows machine that I have no control over)

The idea is to have a different encryption key on every device (which is also tied to an account), so if one gets compromised the other accounts are not affected, but my conversation partners would still only have to verify one public key and automatically have my other public keys certified (if, for example, someone would like to converse with me on both my personal and business address).


My first attempt was to add multiple UIDs (email addresses) and encryption subkeys to a keypair but I soon realized that UIDs belong to the public key and clients by default would only use the most recent encryption key (also see Debian article on how to use a subkey for signing).

My current idea would be to generate a sign-only public key (sign + certify), the root identity, and separate keypairs for each email account (sign + encrypt) and then either certify the keypairs (how?) or build a small web of trust (by setting the trust level "ultimate" "trusted" from the email account keypairs to the sign-only public key?). Is this the way to do it, how would you do it and how can your conversation partners import all of my email public keys by only publishing my master identity?

Also I like to point out this GPG tutorial which argues against using such a type of scheme. The argument being, if I understood it correctly, that you should be more careful with your private key in the first place because users never check revocations anyway. Okay, great, so if my private key is compromised once I'm pretty much screwed with the PGP system? And then again, what's the use of creating a new identity/reputation (Jon Doe the 2nd) if users don't get notified about the revocation of my first identity anyway? I might as well send them a revocation certificate and the new public keys, which are still certified by my old root identity.

3

You already seem to have realized that there is no way to attach user IDs to subkeys.

You cannot impose ultimate trust on others

The problem with your concept is that while you can issue ultimate trust on your own devices, you cannot impose this for other users. If they're able to validate your "master" primary key through the web of trust, the other keys are still to be validated again, with the effect depending on the kind of trust issued on your key and the trust settings of the validating user.

In the end, all you can do is handing over this kind of handling to the others. Sign your other keys with the "master" key (consider certifying them cross-wise) and hope that (if they care to validate keys) they realize this certification and put trust and certifications on the other keys as they require it, too.

Is it worth the effort?

Consider whether using one signing key for multiple devices is not acceptable, anyway and the gained additional benefits don't weigh up with the effort. If somebody gets hold of your encryption subkey, simply revoke it and create a new one; you will still be able to decrypt old messages, and an attacker can only decrypt what he got hold of (so the exposure will usually be the same compared to different encryption subkeys). Consider switching encryption keys more often.

Personally, I only use one encryption subkey on all devices but my mobile phone, which will get its own primary key in the future (which I will not exchange during signing, but only "loosely couple" through cross-certifications.

  • Okay, "ultimate" trust is too much, but if I just use "trusted" isn't that pretty much what the WoT is there for: if they trust my master identity, they also trust my other identities? – Gerold Meisinger Jul 26 '15 at 14:18
  • So, cross-certifying should do the trick? – Gerold Meisinger Jul 26 '15 at 14:25
  • Isn't it very risky to use one encryption key on all devices, even unsafe ones. If the encryption key gets stolen on the company computer, your (old) personal conversation can also be decrypted. – Gerold Meisinger Jul 26 '15 at 14:25
  • Neither of your first two comments apply: you cannot impose any trust on others. Trust is always private/local! For the same reason and as already described, the proposed cross-certifications also only act as indication to the other user to check his trust settings. If you don't trust a device, you probably shouldn't use it at all, and especially not put any keys on it. The consequences of a shared encryption key are obvious and already discussed in the answer. – Jens Erat Jul 26 '15 at 14:31
  • I just read your linked answer. What exactly do you mean by cross-signing? a) personal key signs company key and vice versa (no master key used), or b) master key signs personal key and company key and personal+company key sign master key? – Gerold Meisinger Jul 26 '15 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.