Yubico Forum

Why is there a 64 byte limit for challenges when using the yubikey in Challenge-Response mode?
I can understand that some limit is necessary, but the 64 byte restriction seems a bit arbitrary?

I would like to use a yubikey for implementing an OCRA-based challenge response solution, as specified by the OATH initiative - see http://tools.ietf.org/rfc/rfc6287.txt.
The OCRA algorithm is basically an HMAC-SHA1 over some input data (challenge). See section 5.1 in RFC 6287.

For instance, using the first test vector from section C.1, if the secret key is the Standard 20Byte hex key: 3132333435363738393031323334353637383930 and the OCRA suite is "OCRA-1:HOTP-SHA1-6:QN08" (see section 6), the challenge question "00000000" will yield an input of 152 bytes:

$ (echo -n OCRA-1:HOTP-SHA1-6:QN08; echo -ne '\0'; for i in {1..128}; do echo -ne "\0"; done) | wc -c
152

The response calculation would be:

$ (echo -n OCRA-1:HOTP-SHA1-6:QN08; echo -ne '\0'; for i in {1..128}; do echo -ne "\0"; done) | openssl sha1 -hmac "12345678901234567890" -c
(stdin)= 34:1b:ce:d5:b6:aa:2e:b0:9f:34:d9:3a:06:3c:b5:77:f0:5e:b1:10

where (in this particular case), the first 4 bytes are selected to arive at an OTP:

$ printf "%d" 0x341bced5 | tail -c6
237653

The HMAC-SHA1 calculation could perfectly be performed using a yubikey, if only the input size limit would be lifted a bit:

$ (echo -n OCRA-1:HOTP-SHA1-6:QN08; echo -ne '\0'; for i in {1..128}; do echo -ne "\0"; done) | xxd -p -c256 | xargs ykchalresp -2
Yubikey core error: wrong size

So, I'd like you to consider this a feature request

Cheers,

- Joost

Good Point. However, the current implementation of the HMAC-SHA1 would make it very difficult to expand beyond 64 bytes, as this is the input transaction buffer size.

We might consider that at a later stage, but it is a substantial rework.

_________________
-Tom

Thanks Tom,

Thanks for your answer.
But wouldn't it be possible to provide an update function that would feed the hmac function with 64 bytes at a time?
Similar to the way you would program it in python, for instance:

import hashlib
import hmac
msg='OCRA-1:HOTP-SHA1-6:QN08'
msg += '\0'
msg += 128*'\0'
h=hmac.new("12345678901234567890", msg[0:64], hashlib.sha1)
h.update(msg[64:128])
h.update(msg[128:192])
print h.hexdigest()

Does the YubiHSM have a similar limit on its hmac-sha1 implementation?

No, i don't think that would be possible however I will double check with our hardware guy.

Anyway, what would be the use case, especially for the Yubikey?

_________________
-Tom

Our use case would be to use a Yubikey for challenge/response authentication, similar to existing HMAC-SHA1, but with the OCRA standard, integrating with existing backends in such a way that yubikey can be used as a device to safely store the secret key used in the OCRA algorithm.