Importing existing elgamal subkey fails
Open, NormalPublic


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]
      Keygrip = C95B7086389DF2C7A5C60EA3FAEE535EA9BB5FAB
uid           [ultimate] t1111
ssb   elg2048 2018-12-30 [E]
      Keygrip = 03EA4B12C9942490C46F86EA6BB69FEEF4197928

sec   dsa2048 2018-12-30 [SC]
      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


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.




ooo created this task.Dec 30 2018, 9:33 PM
werner claimed this task.Thu, Mar 7, 8:00 AM
werner triaged this task as Normal priority.
werner added a project: gnupg.