Page MenuHome GnuPG

ed25519 internal authenticate with openpgpcard may send long data over short apdu
Closed, ResolvedPublic


gpg will accept long data (more than 255 bytes) for an internal authenticate with ed25519, for openpgpcard this is passed as-is to the openpgpcard and scdaemon will attempt to send it as a short apdu which will fail. Attached patch sets exmode if indata is > 255

Event Timeline

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.

werner triaged this task as High priority.Fri, Nov 12, 12:53 PM
werner added projects: ssh, scd.
werner changed the task status from Open to Testing.Tue, Nov 16, 5:24 PM