v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt

Steffen Nurpmeso steffen at sdaoden.eu
Mon Jun 4 15:44:13 CEST 2018


Last saturday i search/stumbled over an interesting Debian page
(Subkey.html) which describes how to generate a dedicated siging
subkeys, and how to create a new key pool via
--export-secret-subkeys which does not contain (all parts of) the
real private key, so that the secret key can be stored "somewhere
else" but the newly reimported secret (sub)key can still be used
for signing purposes.
I did not know about that yet, unfortunately, and have started to
use the "normal" key, so that possible users will have to reimport
the updated key.  But because it is a really great thing to be
able to move the complete private key somewhere else, and to have
the remains with a different password at hand, i did that.

So despite the fact that noone is interested in that long story
(sorry), i cannot find a bug in the bug-db that corresponds to the
behaviour i see, and that is that i neither can --export the
public key from that mutilated private key and use that one for
--encrypt'ion, nor can use the key itself for that (the encryption
key seems "hidden", but if i "toggle" --edit-key then i can see it
still).  But i can use it for signing purposes.

My question: is this a bug that --export does not yield a valid
public key that can be used for --encrypt'ion, and that the key as
such cannot be used for that, too?  Shall i open a bug report.


|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

More information about the Gnupg-users mailing list