I am searching test vectors of the HMAC-SHA256 primitive to verify the correctness of an implementation.
Without hesitation I go on the NIST website to see what they offer.
While reading the corresponding file (
HMAC.rsp from hmactestvectors.zip) I can see that the given test vectors associated to the SHA256 hash function are computed with different key sizes: $40$, $45$, $64$ and $70$ (in bytes).
I was a little surprised about this because according to the RFC 4868, the key used should be composed of $32$ bytes:
While no fixed key length is specified in [HMAC], this specification requires that when used as an integrity/authentication algorithm, a fixed key length equal to the output length of the hash functions MUST be supported, and key lengths other than the output length of the associated hash function MUST NOT be supported.
On the other hand, I read:
However cryptographic keys (for symmetric algorithms like HMAC) longer than 128 bits don't really add security, so there is no actual need to go to a full block-length key
That's why these test vectors are getting me confused:
- According to the RFC mentioned above, the key used should be a $256$-bit key.
- It seems that most of the time, HMAC is computed with a $128$-bit key.
But NIST test vectors are using longer keys than the output length (ie $256$ bits because SHA256 is used). Still according to RFC 4868:
key lengths less than the output length decrease security strength, and keys longer than the output length do not significantly increase security strength
So why did the NIST use these key sizes to compute their test vectors? Is it because HMAC algorithm is mainly based on a hash function and it's this feature that requires special assessment? There is also this document which specifies the procedures involved in validating implementations of HMAC but I don't see anything that justify the choice of the key sizes.
To verify the implementation in question is it possible to find other test vectors? Can I consider that if the ones given in RFC 4868 are verified then it's well implemented?