Padding behaviour for 64 byte challenges

[StarGate01]

The genuine Yubikey seems to implement a particular behavior when the challenge is exactly 64 bytes long.
In that case, the last byte is considered padding and ignored, and so are all bytes of the same value preceding it.

This applet always considers the full challenge as data and is thus not compatible with systems that expect a Yubikey and issue a 64 byte challenge.

If you want to test this for yourself, I have attached two bash scripts that use ykchalresp for a USB Yubikey and yktool for a Javacard running this applet or a NFC Yubikey. padding.zip

I will try to fix this issue in a fork and make a PR eventually.

[StarGate01]

I considered that this padding might be PKCS#7, but the challenges [.. 60 bytes ..] 01 01 01 01, [.. same 60 bytes ..] 02 02 02 02 and [.. same 60 bytes ..] produce the same response, indicating that the actual value of the padding bytes is ignored and the last byte is always used as a template. I guess the host application has to worry that the last actual data byte is different from the bytes used for padding.