Page MenuHome GnuPG
Create Task
Maniphest T1501

Public part of a R4096(S)-Subkey lost when imported from an armored backup file.
Closed, ResolvedPublic
Actions

Description

The public part of a R4096(S)-Subkey is skipped when its primary key together
with further subkeys is imported from an ASCII-armored PGP PRIVATE KEY BLOCK
backup file.

For the purpose of reproduction and further testing I attached the
"0x7526FBF74D4020B6_pwd=foo.sec.asc.txt" file to this issue.

This file contains the secret key material with 1 primary and 3 subkeys (R4096;
C,S,E,A). The passphrase is "foo".

When you change the expiry date of the R4096(A) subkey (key 3, expire,
e.g. 1, save), export the secret key in ASCII armored format (gpg
--armor --output 0x7526FBF74D4020B6.sec.asc.txt --export-secret-keys
0x7526FBF74D4020B6), purge it (gpg --delete-secret-and-public-keys
0x7526FBF74D4020B6) and re-import it (gpg --import
0x7526FBF74D4020B6.sec.asc.txt) the sign-only sub-RSA key is not
listed in the pubring.gpg file anymore but still in the secring.gpg
file.

I observed this behavior with gpg Version 1.4.13 and 2.0.19.

If you make gpg's output more verbose with e.g. "gpg -v --status-fd 1 --import
missing_subkey.after.sec.asc" you get:

[...]
gpg: Schlüssel 0x4D4020B6: Ungültige Unterschlüssel-Anbindung
gpg: Schlüssel 0x4D4020B6: Unterschlüssel übersprungen
[...]

Sorry for the output in German. It says something similar to:

[...]
gpg: Schlüssel 0x4D4020B6: Invalid Subkey-Connection
gpg: Schlüssel 0x4D4020B6: Subkey skipped
[...]

Details

Version
1.4.13, 2.0.19

Event Timeline

timfriske added projects: Cross-Compiler, gnupg (gpg14), gnupg (gpg20), gnupg, Bug Report.May 18 2013, 4:46 PM
timfriske set Version to 1.4.13, 2.0.19.
timfriske added a subscriber: timfriske.
timfriske added a comment.May 18 2013, 6:42 PM

I further tried to find the action that causes the potential bug with an another
test key as follows:

  1. Create a certify-only RSA4096 primary key.
  1. Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}
  1. Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --

export 0xEEE9979BE8C80E95

  1. Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --

export 0xB6BF97893ACA0C17

  1. Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95
  1. Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt
  1. Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}
  1. Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.

ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.

timfriske added a comment.May 18 2013, 7:25 PM

In order to work around this potential bug I do the following at the moment:

  1. Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.
  1. Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.

The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.

• werner removed a project: Cross-Compiler.Feb 18 2015, 12:22 PM
• werner added a subscriber: • werner.Jan 21 2016, 4:56 PM

This is caused by gpg inability of merging the secret keys. We can't fix that
in 1.4 or 2.0. 2.1 does not have this problem anymore.

• werner closed this task as Resolved.Jan 21 2016, 4:56 PM
• werner claimed this task.
• werner added a project: Won't Fix.