On Sonntag, 18. April 2021 02:06:40 CEST anon85786376 via Gnupg-users wrote: > When a batch mode key is created with "Subkey-Type: ECC" and "Subkey-Curve: > Ed25519", the key is generated without errors and appears to function > normally. However, importing the secret keys will yield an unusable secret > subkey: [...] > $ gpg -K > /home/me/.gnupg/pubring.kbx > ----------------------------- > sec rsa3072 2021-04-17 [SC] > 1CB8F79F656BCD71BF9A89694C95665DD06F8126 > uid [ unknown] testkey > ssb# ed25519 2021-04-17 [E]
I could reproduce the problem. Note that the "#" next to the subkey indicates that the subkey is just a stub for a secret key. I noticed that after importing there are (as expected) two new files in ~/.gnupg/private-keys-v1.d, e.g. 82380E8EB005D76AE6A1E73FCDC82B374B8D9584.key 05E9DDE401B12A726DF0058FB4F62EACED979CC5.key The names of those files should correspond to the keygrips of the primary key and the subkey. This is true for the primary key, but the keygrip of the subkey does not match. $ gpg -K --with-keygrip FB489AAC37C42F19 sec rsa3072/FB489AAC37C42F19 2021-04-18 [SC] 92AB7959B2905BED251F522DFB489AAC37C42F19 Keygrip = 82380E8EB005D76AE6A1E73FCDC82B374B8D9584 uid [ unknown] testkey ssb# ed25519/2C45A3D965A1FEFE 2021-04-18 [E] Keygrip = B1838BACC3F53C98C675146D7E929AB285C6E49C This seems to be the problem. gpg looks for a file named B1838BACC3F53C98C675146D7E929AB285C6E49C.key which doesn't exist. Please submit a bug report at https://dev.gnupg.org Regards, Ingo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users