Commits ea09b6cded9d31a8ebd91878553c3eaa2b76e817 and acb300543422c660c87ac2f0211a42f792a65cc4 break 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 such as PUBKEY_ALGO_EDDH (with a new value to identify this case such as 23 for instance...) 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;