nisse@lysator.liu.se (Niels Möller) writes:
It's also not directly usable with umac, which takes a nonce (and auto increment in umac*_digest). Should the generic interface try to accomodate macs that require a nonce?
In terms of the meta interface, I guess we could add a set_nonce function to the structure and define it as no-op for other MACs.
I would consider doing it the other way around, and define nettle_hmac_* with fixed key size, for the key sizes used by applications. E.g, https://tools.ietf.org/html/rfc4253#section-6.4 defines 4 mac algorithms based on hmac, with the main one being hmac-sha1, with a fixed key size equal to the digest size of 160 bits.
Is it common to use hmac, without context implying a fix key size ?
Indeed, that would make more sense, given a short key is simply zero-padded to the hash block size.
Slightly related: HMAC is defined as allowing very long keys, by hashing the key in case it's larger than the block size (e.g., 512 bits for hmac-sha1 and hmac-sha256). That seems a bit obscure to me. Are there any applications or protocols depending on that feature?
I think this is a requirement of FIPS as the HMAC definition in FIPS 198-1 explicitly mentions this step.
Regards,