That does not seem to be right. You don't need 255 bytes for an ECC key. It would be best to get scdaemon logs simialr to the gpg-agent logs. Set "debug ipc,cardio" into scdaemon.conf.

Since hashing happens on-card for ed25519 I'm not sure what limits gpg wants to impose, currently the data is passed straight through and scdaemon will happily try to send more than 255 bytes of data as a short apdu here. My patch is probably not correct, I assume it needs to care about cardcap.ext_lc_le and chunking as well.

The internal hashing of ed25519 is not used by OpenPGP but instead we pass the hash of the message to the ed25519 function and thus to the card. Pushing a message through a card is a no-go - way too slow for any normal sized message.

Okay, I revisited the code:

/* Hash data unless we use EdDSA.  */
if ((spec.flags & SPEC_FLAG_IS_EdDSA))
 ....

so you are right, Secure Shell used plain Ed25519 and does not use double hashing. I consider this a bad idea because for longer message you would need to break the ed25519 code of a smartcard apart so that the hashing part can be done by the hos - which is makes things brittle. Thus double hashing is IMHO the only useful way on how to use EdDSA - DJB has a different opinion but he also implemented weird things in qmail ;-)

The upshot is: You are right with your patch and we should deploy sooner than later.

Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.