[Pkg-gnupg-maint] Bug#775559: Bug#775559: gnupg2: New default hashing (SHA256) signing fails with cryptostick/nitrokey (storage version)

[NIIBE Yutaka]

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).
--