Importing/Merging (secret) subkey into existing secret key

Peter Lebbing peter at
Thu Aug 5 13:25:38 CEST 2010

Hash: SHA1

On -10/01/37 20:59, Aaron Whitehouse wrote:
> How do I import a subkey into an existing secret key?

I managed to do this with gpgsplit and recombining. I'm doing this under Linux;
commands for other OSes might differ. Please read the whole mail before starting.

On one machine, I have a key with 2 encryption subkeys, let's say A and B. I
then use these commands:

$ mkdir key1
$ cd key1
$ gpg --export-secret-keys <your keyid> | gpgsplit

Here, the $ sign simply indicates I type it at the prompt, a common convention.
Don't actually include the $. Replace <your keyid> with your... keyid, indeed :).

If I now do a listing of the files in this directory, I see the following:

$ ls
000001-005.secret_key  000002-013.user_id  000003-002.sig
000004-007.secret_subkey  000005-002.sig  000006-007.secret_subkey  000007-002.sig

(sorry for the layout)

These files are the parts that together make up your whole key. Filenames are a
sequence number (increasing), and after the dash the packet type. The packet
type in human readable form is after the dot.

An explanation:

The primary key.

The user id.

The signature binding user id and specifying preferences.

The first secret subkey, encryption key A.

Signature binding A to the primary key.

The second secret subkey, encryption key B.

Signature binding B to the primary key.

You can het more information on these packets with, f.e.:
$ cat * | gpg --list-packets

This will list details about the packets, /in the same order/ as the files. Just

Now, on the second machine I have the same key, only unfortunately it has
encryption subkeys A and C. That is, on the first machine I miss key C and on
the second machine I miss key B.

I start out the same on the second machine:

$ mkdir key2
$ cd key2
$ gpg --export-secret-keys <your keyid> | gpgsplit

The files created will in this case actually have exactly the same names as
described above. The big difference is the contents of the last two files:

Encryption subkey /C/

Signature binding /C/ to the primary key.

Unfortunately, gpg --list-packets does not list the key id's for key packets.
But it does list creation date (in UNIX time format) and expiration date. You
can use these numbers to match up which keys you want to combine. No need to
understand UNIX time format, just match up numbers so that you end up with all
unique subkeys together. You can always throw out unneeded ones later using GnuPG.

Now we want to have subkey C on the first machine. Assuming you've copied the
directory key2 and its contents to the first machine, you can do this:

$ cp key2/000006-007.secret_subkey key1/000008-007.secret_subkey
$ cp key2/000007-002.sig key1/000009-002.sig

Actually, the names are not very important, as long as they are in the same
sorting order as here. I chose to continue the naming GnuPG itself uses.

Now directory key1 has the full key: primary key, and subkeys A, B and C. These
can be combined to form the full key:

$ cd key1
$ cat * >secret_key.gpg

The difficulty you initially ran into is that GnuPG will not import a key it
already has in the keyring, even if the subkeys are different. So after making a
backup of everything, you delete the key already in the keyring. I suggest
making the backup before even starting all this, to avoid disasters if you got
something wrong.

So on both machines, we do:

$ gpg --delete-secret-and-public-keys <your keyid>
$ gpg --import secret_key.gpg

The file secret_key.gpg is what we created in the previous step.

You should now have the full key on both systems.

I hope /I/ didn't do something wrong here, but the backup you made saves you
from disasters in that case.

Note 1: If this is too cryptic, you should not just type in what I say. You need
to understand commands you enter at the prompt, not blindly type in what some
stranger on the internet says. Just ask for more info.

Note 2: I strongly suggest setting the passphrase the same on the two systems,
or you'll run into funny behaviour when it prompts for the passphrase of your
new combined key. You might even want to "change" the passphrase after the
import of the whole key, but change it to the same passphrase you already had. I
won't go into the details, but this will make the key consistent with how GnuPG
normally stores encrypted keys. I don't think GnuPG was ever meant to support
the interesting combining of encrypted keys we do here, even though it works.

On a sidenote, I think it would be cool if GnuPG, on --import, inspected all
subkeys and user id's in a key individually, and add any that are missing. I
think such functionality is useful and intuitive. Perhaps I should create a
feature request ticket.

Good luck,


- -- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at
(new, larger key created on Nov 12, 2009)
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Gnupg-users mailing list