diff options
| author | Kali Kaneko <kali@futeisha.org> | 2015-06-08 17:00:40 -0400 |
|---|---|---|
| committer | Kali Kaneko <kali@futeisha.org> | 2015-06-08 17:00:40 -0400 |
| commit | 28ec72ebe2aac0829b11e016ab21ec52308c0854 (patch) | |
| tree | 1ddeb46cbc0af8ba57ec29c81c43ae39b52d953f /docs/_static/pgp-subkeys.html | |
| parent | 3408b93ee630e01b0905b9bfa849d611bdc52c0a (diff) | |
| parent | 18b6361d66518b5c413c5b893676b87503545274 (diff) | |
Merge branch 'release-2.0.2'
Diffstat (limited to 'docs/_static/pgp-subkeys.html')
| -rw-r--r-- | docs/_static/pgp-subkeys.html | 236 |
1 files changed, 0 insertions, 236 deletions
diff --git a/docs/_static/pgp-subkeys.html b/docs/_static/pgp-subkeys.html deleted file mode 100644 index 2fc83b4..0000000 --- a/docs/_static/pgp-subkeys.html +++ /dev/null @@ -1,236 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html><head><title>Using multiple subkeys in GPG</title></head><body style="background-color: white;"> -<div>[ <a href="http://fortytwo.ch/">main gpg page</a> ] -<hr> -<h1>Using multiple subkeys in GPG</h1> -<hr> -<h2>Motivation</h2> -<p> -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. -</p> -<p> -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. -</p> -<p> -<b>NOTE:</b> 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 <a href="#problems">Problems</a> 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. -</p> -<p> -The following is based on <b>gnupg 1.2.1</b>. 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. -</p> -<h2>Basics</h2> -<p> -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. -</p> -<p> -Then "<tt>gpg __edit <i>keyid</i></tt>" the key and add a further subkey -using "<tt>addkey</tt>". "<tt>save</tt>" will store the new subkey on the -keyring. You'll want to save the whole key (secret and public) with -"<tt>gpg __export <i>keyid</i> > pubkey</tt>" and "<tt>gpg -__export-secret-key <i>keyid</i> > seckey</tt>". 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 <a href="http://www.gnupg.org/gph/en/manual.html">some -reading</a> before continuing here). -</p> -<p> -Now you should also <b>back up your keyrings</b>, as the following has to -work on a keyring to work around some missing or broken gpg features. -</p> -<p> -As you probably will only take one of the subkeys to your not-so-secure -location, "<tt>gpg __edit <i>keyid</i></tt> and delete the subkeys you -don't want to expose (mark them with "<tt>key <i>n</i></tt>" and then delete -them with "<tt>delkey</tt>"). -</p> -<p> -"<tt>gpg __export-secret-subkeys <i>keyid</i> > crippled.seckey</tt>" -will then export the remaining subkeys, without the keymaterial of the -primary key. -</p> -<p> -Now, you can restore the keyrings (secret <em>and</em> 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, "<tt>gpg __edit <i>keyid</i></tt>", -"<tt>key <i>n</i></tt>" and "<tt>delkey</tt>" takes care of this; again, it -is necessary to re-import the public key. -</p> -<p> -On your 'insecure' machine, you do "<tt>gpg __import pubkey -crippled.seckey</tt>" (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 "<tt>gpg -__list-secret-keys</tt>": all primary secret key where the key material is not -present are marked with '#'. -</p> -<pre> -$ gpg __list-secret-key testuser -sec<b>#</b> 1024D/971B7A70 2003-01-03 testuser <testuser@mydomain.foo> -ssb 1024g/ACDF80C4 2003-01-03 -ssb 1024R/BE9CA308 2003-01-07 -</pre> -<p> -Of course, you'll have to publish your new public key, so people can -verify your signatures and send you encrypted mail. Read the <a -href="#problems">Problems</a> section for a few comments about this. -</p> -<h2>Effects</h2> -<p> -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. </p> -<p> -You will always be able to revoke a subkey (just "<tt>gpg __edit -<i>keyid</i></tt>", "<tt>key <i>n</i></tt>" and "<tt>revkey</tt>") 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. -</p> -<p> -If you're signing documents, gpg will always try to use a subkey if one -is available, and announce this with a message like "<tt>1024-bit DSA key, ID -E5A7F7D6, created 2002-08-22 (main key ID 92082481)</tt>" . 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 -"<tt><i>keyid</i>!</tt>" 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 <a href="http://www.gnupg.org/documentation/mailing-lists.html">gnupg -mailing list archives</a>. -</p> -<h2><a name="problems">Problems</a></h2> -<p> -The above approach has several problems that may lead to you not doing -things like this. <b>These are not just possible problems. These are real, -and <em>will</em> affect you! You have been warned.</b> -</p> -<p> -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 -"<tt><i>keyid</i>!</tt>" syntax. The presence of multiple encryption subkeys -is, however, useful if you revoke an older one to replace it with a new one. -</p> -<p> -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). -</p> -<p> -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 <tt>subkeys.pgp.net</tt>. -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). -</p> -<p> -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. -</p> -<p> -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.: -</p> -<ul> -<li> -"<tt>gpg __import <i>secret key</i></tt>" 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 -"<tt>__export</tt>"s at all stages and use "<tt>__delete-secret-key</tt>" -often. (People with masochistic inclination may probably also use -combinations of <tt>gpgsplit</tt>, <tt>cat</tt> and "<tt>gpg __export</tt>" -and "<tt>__import</tt>. I've not tried this.) -</li> -<li> -"<tt>gpg __export-secret-key <i>keyid</i>!</tt>" and <tt>gpg -__export-secret-subkeys <i>keyid</i>!</tt>" should really only export the -named subkey (or the primary stripped of all subkeys). Much keyring shuffling -could be avoided. (<b>2003-02-12:</b>David Shaw added this to the development -branch of the gpg code. Great!) -</li> -</ul> -<h2>Links</h2> -<p> -Some additional reading that might be interesting: -</p> -<ul> -<li> -The <a href="http://www.ietf.org/rfc/rfc2440.txt">rfc2440</a>, specifying -the OpenPGP key format. -</li> -<li> -The <a href="http://www.gnupg.org/gph/en/manual.html">GNU Privacy Handbook</a> -is a fairly complete manual to gpg. -</li> -<li> -The <a -href="http://lists.gnupg.org/pipermail/gnupg-users/2002-August/014721.html">using -various subkeys</a> thread on the gnupg-users mailing list, where most of these -issues were discussed. -</li> -<li> -The <a -href="http://lists.gnupg.org/pipermail/gnupg-devel/2002-September/007700.html">using -subkey signatures</a> thread on gnupg-devel where I asked about the auto key -retrieval problem. -</li> -<li> -Other <a href="http://atom.smasher.org/gpg/">tutorials</a> on advanced black -magic with keys by Atom Smasher, dealing with what you can do with subkeys. -</li> -</ul> -<h2>Acknowledgments</h2> -<p> -Of course, thanks to the gnupg crew for the cool software, and especially to -Werner Koch and David Shaw for replying to my initial questions about this. And -to Jason Harris for fixing pks to accept keys with multiple subkeys, I hope -this patch spreads really fast as soon as it is officially out. -</p> -<p> -</p> -</div> -<hr> -<div style="font-size: x-small;"> -©2002-2004 <a href="mailto:avbidder+gpg@fortytwo.ch">Adrian von Bidder</a> -- Permission to redistribute and/or modify this document is granted if (i) the -original author (Adrian von Bidder, Switzerland) is acknowledged and (ii) the -document remains freely available for distribution and modification. -</div> - -</body></html> |