Thank you for your report. On 01/17/2015 08:55 PM, Luca Bruno wrote: > With the latest gnupg2 package targeted for the Jessie, defaulting hashing > algorithm has been changed to SHA256. This broke my smartcard setup using a > cryptostick/nitrokey (storage version, latest 0.18 firmware) as signing now > fails with:
It would be cryptostick/nitrokey specific, perhaps. In the Debian community, use of SHA256 hash has been recommended for years and many Debian developers have such configuration (including me). And this is the first report I got which describes hash matters when signing with smartcard/token. > scdaemon[7609]: chan_7 <- SETDATA > D4C076C2A0E30219D4631EDF85E8844C41EA950A8549D0B3A7BD4D18D550CD8A > scdaemon[7609]: chan_7 -> OK OK, the hash of SHA256 is 32-byte. > 2015-01-17 12:21:07 scdaemon[7609] DBG: send apdu: c=00 i=2A p1=9E p2=9A > lc=51 le=2048 em=1 This is issuing PSO:SIGN command. The length of message with SHA256 should be 51, and it's good (lc=51). Well, cryptostick/nitrokey uses extended APDU, it seems. > 2015-01-17 12:21:30 scdaemon[7609] ccid_transceive failed: (0x1000a) > 2015-01-17 12:21:30 scdaemon[7609] apdu_send_simple(0) failed: card I/O error > 2015-01-17 12:21:30 scdaemon[7609] operation sign result: Input/output error > 2015-01-17 12:21:30 scdaemon[7609] app_sign failed: Input/output error > scdaemon[7609]: chan_7 -> ERR 100696113 Input/output error <SCD> ... and you didn't got anwser. I guess that there were something in the lower layer. > * I see a response with datalen=0, but I don't know the protocol. > Maybe something went wrong there? No, 9000 is "OK", and datalen=0 means "OK with no reply" (response from VERIFY command). It's usual response. > * Using SHA1, operation succeeds and the dongle response apdu is > "response: sw=9000 datalen=511" Yes, such a response is expected (when your key is RSA-4096). If it's not absolute requirement, I usually recommend not to use pcscd, but just use in-stock CCID driver of GnuPG to access smartcard readers or tokens. If you have time, please consider to try testing without pcscd. Newer GnuPG's in-stock CCID driver is good enough for most of USB CCID readers and tokens. Actually, in the past (time around libusbx 1.0.9 or so), I had troubles with libusbx for long data, and this is one of major reasons why I stop using extended APDU for my own project (Gnuk Token). -- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
