diff options
Diffstat (limited to 'docs/gpg-migrate.txt')
| -rw-r--r-- | docs/gpg-migrate.txt | 208 |
1 files changed, 0 insertions, 208 deletions
diff --git a/docs/gpg-migrate.txt b/docs/gpg-migrate.txt deleted file mode 100644 index 1d07450..0000000 --- a/docs/gpg-migrate.txt +++ /dev/null @@ -1,208 +0,0 @@ -# taken from http://atom.smasher.org/gpg/gpg-migrate.txt on 8 Aug 2013 - ------BEGIN PGP SIGNED MESSAGE----- -Hash: SHA1 - -HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY - -this document [is intended to] explain how to migrate a key or subkey from -one OpenPGP key into another OpenPGP key. - -here i'll walk you through the steps of migrating my old primary signing -key (3D7D41E3) into my new key (D9F57808). the process of migrating -encryption (and signing) subkeys is nearly identical. for the adventurous, -you can even migrate several keys at once using this method (i recommend -going through it once or twice with only one key). - -============================================================================ - -doing this requires: - 1) basic knowledge of a *nix command line and how to use it - 2) advanced knowledge of gpg and how to use it - 3) common sense (BACKUP YOUR DATA!!) - -please note: - * this works for me. that does not necessarily mean that it will - work for you - * if you screw something up, it's *YOUR* problem, not mine - * this was tested with GnuPG 1.2.4, and written on or about - 12 May 2004 - * updates, if there are any, will probably be noted above - * comments and suggestions about this tutorial should be sent to: - <atom {at} smasher.org> - * questions about gpg should be sent to the gnupg-users mailing - list: http://lists.gnupg.org/mailman/listinfo/gnupg-users - -============================================================================ - -* old key: 3EBE 2810 30AE 601D 54B2 4A90 9C28 0BBF 3D7D 41E3 - -pub 1024D/3D7D41E3 2003-10-04 Atom Smasher <atom@suspicious.org> -uid Atom Smasher <atom@smasher.org> -sub 2048g/1E88BF71 2003-10-04 [expires: 2005-01-26] - -================ - -* new key: 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - -pub 4096R/D9F57808 2004-05-11 Atom Smasher <atom@smasher.org> -uid Atom Smasher <atom@suspicious.org> -sub 1024D/3D7D41E3 2003-10-04 [expires: 2006-02-13] -sub 2048g/1E88BF71 2003-10-04 [expires: 2006-01-26] - -=================================== - -backup the new keys: - $ gpg --export D9F57808 > D9F57808_original.txt - $ gpg --export-secret-key D9F57808 > D9F57808_original_secret.txt - -and the old keys: - $ gpg --export 3D7D41E3 > 3D7D41E3_original.txt - $ gpg --export-secret-key 3D7D41E3 > 3D7D41E3_original_secret.txt - -break the old secret key into pieces: - $ gpg --export-secret-key 3D7D41E3 | gpgsplit -vp OLD_SEC - -=================================== - -in this case, the old primary key needs to be converted into a subkey. -pgpdump shows that it's a primary key: - $ pgpdump OLD_SEC000001-005.secret_key - Old: Secret Key Packet(tag 5) - <<snip>> - -only do this if you're converting a PRIMARY KEY into a SUBKEY: open that -file in a hex editor and refer to RFC2440 4.2 & 4.3. i recommend setting -the hex editor into a binary display. in this example the first byte is -"10010101" and it needs to be changed to "10011101". the change can be -confirmed with pgpdump: - $ pgpdump OLD_SEC000001-005.secret_key - Old: Secret Subkey Packet(tag 7) - <<snip>> - -we've now converted the old primary key into a subkey. if you're moving a -subkey from one key to another, you don't have to do that. - -=================================== - -use "edit-key" and add a subkey of the same type (DSA, for this example) -and size to the new key. this subkey will be discarded, but we need to -generate it for now: this seems to be the quickest way to generate a -keybinding signature with the correct features. - -exit from "edit-key" and save. - -=================================== - -split the current version of the new public key: - $ gpg --export D9F57808 | gpgsplit -vp TEMP_KEY1 -the only part we need from that split is the binding signature that was -just generated. - -delete (from the keyring) both the private and public copies of the new -key: - $ gpg --delete-secret-key D9F57808 - $ gpg --delete-key D9F57808 - -also delete (from the keyring) both the private and public copies of the -old key. - -because the subkey that we're adding to the new key does not correspond to -the subkey binding signature that was created for it, gpg will not allow -the key to be imported. the way around that is to "force feed" the key into -the keyring, bypassing the normal sanity checks. once it's in the keyring -we can make it all work. - -* note: the actual file names that you're using may differ somewhat from -mine. when in doubt (or rather, when you're not sure), use pgpdump to -examine the contents of files. - -~import~ (directly into the secret keyring) the original copy of the new -key (D9F57808_original_secret.txt), the edited copy of the old primary key -(now a subkey, OLD_SEC000001-005.secret_key) and the binding signature of -the subkey that we just generated (TEMP_KEY1000007-002.sig): - $ cat D9F57808_original_secret.txt \ - OLD_SEC000001-005.secret_key \ - TEMP_KEY1000007-002.sig >> ~/.gnupg/secring.gpg - -~import~ (directly into the public keyring) a public key by adding -"| gpgsplit --no-split --secret-to-public" to the above command like this: - $ cat D9F57808_original_secret.txt \ - OLD_SEC000001-005.secret_key \ - TEMP_KEY1000007-002.sig \ - | gpgsplit --no-split --secret-to-public >> ~/.gnupg/pubring.gpg - -now we have to make a *valid* keybinding signature for the subkey that we -just added. use "edit-key", select the newly added subkey, and reset it's -expiration date. that will generate a valid keybinding signature. - -while in "edit-key", reset the password. otherwise you may inadvertently -create a key with multiple passwords, as described here - - http://atom.smasher.org/gpg/gpg-passwords.txt - -exit from "edit-key" and save. - -========================= - -this last part makes no sense to me (but it doesn't seem to work -otherwise). - -back up (export) the latest version of the public and private keys: - $ gpg --export-secret-key D9F57808 > new-key.sec - $ gpg --export D9F57808 > new-key.pub - -delete (from the keyring) the private and public key: - $ gpg --delete-secret-key D9F57808 - $ gpg --delete-key D9F57808 - -also, delete (from the keyring) all copies of the old (sub)key that was -just added to the new key. - -import the new public and private keys: - $ gpg --import new-key.sec new-key.pub - -========================= - -before you publish your new key: - -* make sure the key is "ultimately trusted". deleting and importing will -have removed it from the trust db. since you own the key, ultimate trust -seems reasonable. - -* check all expiration dates and preferences. some of these operations may -have changed your expiration dates and preferences; reset as necessary. - -* test out all key components for creating and verifying signatures, and -encryption/decryption. use the bang (!) to force each (sub)key: - create & verify signatures: - $ date | gpg -u 'D9F57808!' --clearsign | gpg -v --verify - $ date | gpg -u '3D7D41E3!' --clearsign | gpg -v --verify - encrypt/decrypt: - $ date | gpg -ear 'D9F57808!' | gpg -v --decrypt - $ date | gpg -ear '1E88BF71!' | gpg -v --decrypt - -* after testing out the keys locally, send your new public key to one or -two people and test all key components (sending signed/encrypted messages -to each other using all key components). make sure that they first delete -(from their keyrings) your old key! and make sure that they understand that -the key should NOT be circulated until all functions are verified to be -working! - -* when putting the new key into circulation, it's probably a good idea to -expire/revoke the old key. include a revocation comment that specifies the -new key ID and instructions to delete the old key from the keyring. - -* note on key revocation: according to the OpenPGP standards a revocation -generated by a sub key will be ignored, unless that subkey has been -designated (by the primary key) as a revocation key. GnuPG seems to behave -correctly, but some versions of PGP(tm) may not. if someone is claiming -that your new key is revoked, have then remove all of your old and current -keys from their keyring: then re-import your current key(s). - ------BEGIN PGP SIGNATURE----- -Version: GnuPG v1.2.4 (FreeBSD) - -iD8DBQFApwlpnCgLvz19QeMRAhrpAJ4rhLrmVDjABh8CpPdTZ5jNMi7LsgCgp35S -6qcUe4csx1p5AE2rAsvDi9c= -=y7bA ------END PGP SIGNATURE----- |