Because of PQ crypto which size is larger, the data to be signed (with Ed25519) is too large (something like 330-byte). It's not OpenPGP which does double-hashing, the protocol uses bare data to be signed (not hashed beforehand).
While it can be signed by token/smartcard (at least with newer Gnuk), as long as it is smaller than the buffer size, scdaemon itself rejects, not asking token/smartcard.
With newer Gnuk Token, following patch should work:
diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 05e1f3977..439052f8c 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -5490,6 +5490,11 @@ do_auth (app_t app, ctrl_t ctrl, const char *keyidstr, exmode = 1; /* Use extended length. */ le_value = app->app_local->keyattr[2].rsa.n_bits / 8; } + else if (app->app_local->cardcap.cmd_chaining && indatalen > 254) + { + exmode = -254; /* Command chaining with max. 254 bytes. */ + le_value = 0; + } else if (indatalen > 255) { if (!app->app_local->cardcap.ext_lc_le)
I'll test soon.
There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).
We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?
Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.
I was trying locate the place where it returns GPG_ERR_INV_VALUE.
It seems that it is Yubikey which errors (not scdaemon itself).
I'll check with Yubikey.
My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) (key Ed25519) works fine with OpenSSH using kex of sntrup761x25519-sha512@openssh.com.