Commits ea09b6cded9d31a8ebd91878553c3eaa2b76e817 and acb300543422c660c87ac2f0211a42f792a65cc4 breaks the possibility to generate ECC encryption key on-card when any curve other than 25519 is used.
The problem comes from the fact that PUBKEY_ALGO_ECDH is both used for 25519 and non-25519 curves.
The problem does not appear for signature and authentication keys as PUBKEY_ALGO_EDDSA is used for 25519 and PUBKEY_ALGO_ECDSA for non-25519 curves. The patch below fixes the problem, but will break the "magic trick" introduced for GnuK...
A possible solution is to use another constant (with a new value to identify this case such as 23 for instance...), like PUBKEY_ALGO_EDDH for encryption with 25519, and leave PUBKEY_ALGO_ECDH for non-25519 curves, as previously.
Index: gnupg/g10/card-util.c
===================================================================
--- gnupg.orig/g10/card-util.c
+++ gnupg/g10/card-util.c
@@ -1486,7 +1486,7 @@ generate_card_keys (ctrl_t ctrl)
for (keyno = 0; keyno < DIM (info.key_attr); keyno++)
{
if (info.key_attr[keyno].algo == PUBKEY_ALGO_RSA
- || info.key_attr[keyno].algo == PUBKEY_ALGO_ECDH
+ //|| info.key_attr[keyno].algo == PUBKEY_ALGO_ECDH
|| info.key_attr[keyno].algo == PUBKEY_ALGO_EDDSA)
{
if (info.key_attr[keyno].algo == PUBKEY_ALGO_RSA)
@@ -1572,7 +1572,7 @@ card_generate_subkey (ctrl_t ctrl, kbnod
if (info.is_v2 && info.extcap.aac)
{
if (info.key_attr[keyno-1].algo == PUBKEY_ALGO_RSA
- || info.key_attr[keyno].algo == PUBKEY_ALGO_ECDH
+ //|| info.key_attr[keyno].algo == PUBKEY_ALGO_ECDH
|| info.key_attr[keyno].algo == PUBKEY_ALGO_EDDSA)
{
unsigned int nbits;