GPG keys for multiple email accounts

[Hauke Laging]

Am Sa 06.07.2013, 19:53:16 schrieb Tim Chase:

> This was an amazingly helpful email.  I've seen a lot of posts (both
> blog and here on the mailing list) that are full of technical
> explanations, but very few that go over best practices for managing
> multiple identities.

I often help people create high quality keys and even try to educate future 
instructors (http://www.openpgp-courses.org/). I was forced to think about 
that a lot...


> I too juggle several dozen email addresses
> (many of which come to a single catch-all mailbox, but help in
> filtering the incoming deluge), so if you know of any "Best practices
> in managing multiple GPG identities for dummies" resources, I'd love
> to become better versed at whatever links you provide.

That's a new situation for me; I am not aware of resources which cover that. 
But what comes to my mind: Is it really necessary that each of these addresses 
becomes a user ID? Technically it is not a problem to send an email to 
foo at example.org but encrypt it to the key with the single UID bar at example.org. 
You just have to configure the mail client that way. And the mail client wants 
(at least once) a confirmation for the key to be used anyway. Whether this is 
an option probably depends on the precise circumstances how you use these 
addresses.

You may even create ten UIDs but publish only one of them. For every address 
you create a version of the public key (certificate) which contains the main 
UID and the one for that address. Due to "stupid" keyservers and users it can 
happen though that the recipients of these keys upload them to a keyserver so 
that these UIDs appear in the public unwantedly.


> > You should NEVER use mainkeys outside a safe environment (boot from
> > CD/DVD). Only subkeys should be used on normal systems.
> 
> Could you explain this a little more?  This sounds very important,
> but I feel I'm not grasping the interplay of mainkeys vs. subkeys and
> how they are (or should be) accessed.

The relevant key word is "offline mainkey". Ask your favorite search engine. I 
have written a few articles for the KDE userbase wiki which cover that:

http://userbase.kde.org/Concepts/OpenPGP_Getting_Started#Main_key_and_subkeys

There are English tutorials for this. I can offer mine in German only:

http://www.openpgp-schulungen.de/inhalte/einrichtung/materialien/keygen-anleitung.html

I have written a quite comprehensive bash script for the generation of good 
keys (with an offline mainkey, of course). Up to now this is in German only, 
though:

http://www.openpgp-schulungen.de/scripte/keygeneration/#download

We really need the GUIs to get better.


> I'd understood that unlocking
> a keyring got you access to all the keys on it, so accessing a
> sub-key in a non-safe environment would potentially risk exposing
> your mainkey as well.  I suspect I've missed something important.

That is completely wrong. A keyring is not unlocked. Single keys are decrypted 
(and cached). And "single keys" means that a mainkey and all of its subkeys 
have to be "unlocked" separately. I am not sure but I guess that gpg-agent 
does not cache the passphrase but the decrypted key instead. Thus even though 
gpg cannot set different passphrases for different components of the same key, 
you have to enter the same passphrase three times if you have two subkeys and 
first decrypt something then sign something and at last certify something.

The mainkey is in danger if its passphrase is ever entered on an insecure 
system (if it is not physically really secure). Thus the mainkey should have a 
passphrase different from that of the subkeys. The mainkey passphrase should 
be cryptographically secure (16+ chars). As long as you never enter this 
secure passphrase in an insecure environment you can even store the secret 
mainkey in the same keyring as the subkeys (which requires some tricks and is 
of no use at all).


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20130707/55d87653/attachment-0001.sig>