Using multiple subkeys in GPG

Motivation

-For a time, I've had two different gpg keys - one at home on my presumably -secure machine, one at the office, with NFS mounted home directory and -quite a few people having accounts everywhere. This worked, but the problem -is that when exchanging key signatures I always had to beg people to sign -both my keys. -

-With gpg and the possibility of having multiple subkeys, I can now have -only one key, but still retain the security feature that I don't have to -revoke my primary key (and lose all signatures on it) if the key at the -office is compromised. -

-NOTE: Most of the following can apply to both signing and encrypting -subkeys. Encryption subkeys can not be used to solve the multiple accounts -problem, though, please see the Problems section -further down. Also, note that I don't use multiple encryption subkeys, so I -don't know if there are additional problems with them. -

-The following is based on gnupg 1.2.1. It should all work with newer -versions, too. Older versions do not support everything and have some -additional problems. As I really do recommend you use a recent gpg version, I -have omitted anything related to older gpg versions. -

Basics

-Generate a normal key pair, or use an existing key. Usually this will be a -DSA/ElGamal key (this is what I use), but using RSA or other keys is -equally possible. Be sure to do this on a 'really secure' machine. -

-Then "gpg __edit keyid" the key and add a further subkey -using "addkey". "save" will store the new subkey on the -keyring. You'll want to save the whole key (secret and public) with -"gpg __export keyid > pubkey" and "gpg -__export-secret-key keyid > seckey". Best copy those files -onto an offline storage, too. (A basic working knowledge of how to use a -command line and how to deal with files is assumed. Also, you should know -a bit how key handling in gpg works. If you can't see what the above commands -do, you better do some -reading before continuing here). -

-Now you should also back up your keyrings, as the following has to -work on a keyring to work around some missing or broken gpg features. -

-As you probably will only take one of the subkeys to your not-so-secure -location, "gpg __edit keyid and delete the subkeys you -don't want to expose (mark them with "key n" and then delete -them with "delkey"). -

-"gpg __export-secret-subkeys keyid > crippled.seckey" -will then export the remaining subkeys, without the keymaterial of the -primary key. -

-Now, you can restore the keyrings (secret and public, since -deleting the subkeys has also deleted the public subkeys!), and your secure -machine is ready to use. Perhaps you don't want to use your 'insecure' -subkey on your secure machine - again, "gpg __edit keyid", -"key n" and "delkey" takes care of this; again, it -is necessary to re-import the public key. -

-On your 'insecure' machine, you do "gpg __import pubkey -crippled.seckey" (the same files you've generated above), now you're ready -to use gpg on the 'insecure' machine. To verify that you really don't have any -secret keys you don't want, have a look at the output of "gpg -__list-secret-keys": all primary secret key where the key material is not -present are marked with '#'. -

-$ gpg __list-secret-key testuser
-sec# 1024D/971B7A70 2003-01-03 testuser <testuser@mydomain.foo>
-ssb  1024g/ACDF80C4 2003-01-03
-ssb  1024R/BE9CA308 2003-01-07
-

-Of course, you'll have to publish your new public key, so people can -verify your signatures and send you encrypted mail. Read the Problems section for a few comments about this. -

Effects

-Keys are always signed with your primary key, so you (or any attacker) won't be -able to sign other keys with the key on the 'insecure' machine. This is why we -started doing all this acrobatics after all.

-You will always be able to revoke a subkey (just "gpg __edit -keyid", "key n" and "revkey") when you -have the primary secret key available, even if you lose your secret subkey. -Meaning: you may use a secret subkey at an office location, and it is not -strictly necessary to back it up on a secure location (It's still a good idea, -though). The reason for this is that a revocation is really a signature on the -subkey - and this signature is done with the primary key. Of course, this means -that you can't revoke a subkey when you don't have the primary secret key. -

-If you're signing documents, gpg will always try to use a subkey if one -is available, and announce this with a message like "1024-bit DSA key, ID -E5A7F7D6, created 2002-08-22 (main key ID 92082481)" . Verifying such -signatures used to cause a similar message, but at least with gpg 1.2.3 no -indication is given that the signature was made with a subkey. If you want to -use a specific subkey (or the primary key), you have to specify it with the -"keyid!" syntax. I don't remember what happens if more than one -signing subkey is available; I'm sure you can find details on this somewhere in -the gnupg -mailing list archives. -

Problems

-The above approach has several problems that may lead to you not doing -things like this. These are not just possible problems. These are real, -and will affect you! You have been warned. -

-First, distributing secret subkeys this way (one subkey for each -account/machine you use) only makes sense with signing subkeys. You can have -multiple encryption subkeys, but you can't force people sending you encrypted -mail using a specific subkey. Naturally, if you're using encryption for -yourself, you can chose the encryption key to use with the -"keyid!" syntax. The presence of multiple encryption subkeys -is, however, useful if you revoke an older one to replace it with a new one. -

-Old PGP versions apparently can't cope with such keys. I didn't verify this -myself, but people on the gnupg-users mailing list said that current PGP -versions (up to 7.x) can not verify signatures from a subkey. With PGP 8 the -situation is a bit more complicated: PGP 8 can verify subkey signatures, but -has still problems with multiple subkeys: a key with a signing subkey that is -newer than the encryption subkey cannot be used for encryption in PGP 8. A key -where the encryption subkey is newer than the signing subkey can be used for -encryption. So, when you create your key, generate it as 'signing only' key -first, then generate all the signing subkeys you need, and in the end generate -the encryption subkey. (Thanks to David Shaw for this info). -

-Most keyservers can not handle keys with multiple subkeys. Some of them even -make these keys unusable. This should get better soon, as JHarris has written a -patch for the pks keyserver, and keyservers with other software that handles -this are deployed more widely. The keyservers that can handle multiple subkeys -are summarized as subkeys.pgp.net. -GnuPG 1.2 added code to recover somewhat when a broken key is retrieved - one -of the subkeys is useable (the others can't be used, as the signature binding -the subkey to the primary is lost). -

-Besides corrupting keys with multiple subkeys, all of these old keyservers -will also only search keys based on the primary key id - so, automatic key -retrieval on signature verification will not work, too. Yet another -reason to oonly use the subkeys.pgp.net keyservers. -

-Finally, keyhandling is not comfortable with such keys - the user interface of -gpg could be better. The following is valid for gpg 1.2.1, some things may be -fixed in newer versions.: -

-"gpg __import secret key" does not merge the keys properly. -If a secret key is already present, additional secret subkeys are not -imported. Also, a dummy primary key is not replaced by the real subkey on -import. Workaround is to shuffle around the keyrings, or do -"__export"s at all stages and use "__delete-secret-key" -often. (People with masochistic inclination may probably also use -combinations of gpgsplit, cat and "gpg __export" -and "__import. I've not tried this.) -
-"gpg __export-secret-key keyid!" and gpg -__export-secret-subkeys keyid!" should really only export the -named subkey (or the primary stripped of all subkeys). Much keyring shuffling -could be avoided. (2003-02-12:David Shaw added this to the development -branch of the gpg code. Great!) -

Acknowledgments