I am trying to use the subkey import feature introduced in 958f29d2251a96d09439e591ea3523133930e5e9 with elgamal subkeys.
I get the following error:
$ gpg2 --quick-gen-key t1111 ... $ gpg2 --quick-gen-key t2222 ... $ gpg2 --list-secret-keys --with-keygrip sec dsa2048 2018-12-30 [SC] E78313BF3003F8D35BFB10A2932F81E5D36C571E Keygrip = C95B7086389DF2C7A5C60EA3FAEE535EA9BB5FAB uid [ultimate] t1111 ssb elg2048 2018-12-30 [E] Keygrip = 03EA4B12C9942490C46F86EA6BB69FEEF4197928 sec dsa2048 2018-12-30 [SC] 9FC602D892147134BC0A62D4B1957C64B6D62DA3 Keygrip = F0A1DDB845691EC376516BAEF256D7472EAA1463 uid [ultimate] t2222 ssb elg2048 2018-12-30 [E] Keygrip = B056F8D9D0CA6BC4F965A2AA77F21A3D032E27A2 $ gpg2 --expert --edit-key E78313BF3003F8D35BFB10A2932F81E5D36C571E ... gpg> addkey Please select what kind of key you want: ... (13) Existing key Your selection? 13 Enter the keygrip: B056F8D9D0CA6BC4F965A2AA77F21A3D032E27A2 Possible actions for a ELG key: Current allowed actions: (Q) Finished Your selection? ... Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y gpg: Key generation failed: Internal error gpg>
It seems that at [0] the check_keygrip functions somehow returns PUBKEY_ALGO_ELGAMAL, when in fact it should return PUBKEY_ALGO_ELGAMAL_E.
Indeed if I break there with gdb and adjust the algo variable from 20 to 16, then the import works as expected.
Interestingly I found commit b7f8dec6325f1c80640f878ed3080bbc194fbc78 which happens to change check_keygrip in a way that should prevent forgetting the _E for the algorithm (I did not actually test this). Though this commit is not even in 2.12 yet and I don't really understand why to be honest.
On a sidenote: can you think of a more userfriendly workaround to this problem (other than using gdb)? I tried to manually add the subkey using gpgsplit following some old tutorials I found. But I cannot get any recent gpg to actually present me a key with broken/missing signature in edit-key mode, so I could re-certify it.
The issue is kind of annoying for us. We are dealing with a frontend that can handle just one private key at once (horde webmail). And we somehow need to support users migrating away from old elgamal keys, while preserving access to existing mail.
Thanks