1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
# 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-----
|
