I'm looking into refactoring hmac, mainly to trim context size https://git.lysator.liu.se/nettle/nettle/-/issues/2.
Two questions somewhat related to this:
1. The hmac spec allows arbitrarily large keys; if key size exceeds underlying block size, the key is hashed and the digest is used as the hmac key. Effectively the same as if caller would hash the key, and pass in the digest. Is this a feature that anyone is using, or in other words, what would break if nettle's hmac implementation were restricted to key size <= block size, and leave the obscure(?) prehashing needed for support of arbitrary large keys to the application?
2. That kind of prehashing is also a usecase for all-in-one hashing. Would it be useful to add convenience functions for all-in-one-hashing, e.g.,
void sha256_sum (uint8_t *digest, size_t length, const uint8_t *data);
to hash a contiguous string without having to bother with init/update/digest? Implementation would typically need to allocate a context struct on the stack.
Regards, /Niels
Niels Möller nisse@lysator.liu.se writes:
I'm looking into refactoring hmac, mainly to trim context size https://git.lysator.liu.se/nettle/nettle/-/issues/2.
Two questions somewhat related to this:
- The hmac spec allows arbitrarily large keys; if key size exceeds underlying block size, the key is hashed and the digest is used as the hmac key. Effectively the same as if caller would hash the key, and pass in the digest. Is this a feature that anyone is using, or in other words, what would break if nettle's hmac implementation were restricted to key size <= block size, and leave the obscure(?) prehashing needed for support of arbitrary large keys to the application?
I've seen applications pass in human password strings into HMAC, which are sometimes longer than the block size resulting in the extra hash step. This is usually bad practice (use scrypt or argon2 instead) but exists.
That kind of prehashing is also a usecase for all-in-one hashing. Would it be useful to add convenience functions for all-in-one-hashing, e.g.,
void sha256_sum (uint8_t *digest, size_t length, const uint8_t *data);
to hash a contiguous string without having to bother with init/update/digest? Implementation would typically need to allocate a context struct on the stack.
Yes! I find such APIs really useful. Many applications create a similar one internally.
/Simon
Regards, /Niels
Simon Josefsson simon@josefsson.org writes:
I've seen applications pass in human password strings into HMAC, which are sometimes longer than the block size resulting in the extra hash step. This is usually bad practice (use scrypt or argon2 instead) but exists.
I'm leaning towards deleting this support (leaving extra hashing to applications that need it) for Nettle-4.0, to keep things simple. It can be added back later if there are compelling use cases.
void sha256_sum (uint8_t *digest, size_t length, const uint8_t *data);to hash a contiguous string without having to bother with init/update/digest? Implementation would typically need to allocate a context struct on the stack.
Yes! I find such APIs really useful. Many applications create a similar one internally.
Filed https://git.lysator.liu.se/nettle/nettle/-/issues/12. Is '_sum' a good name? Some alternatives, '_hash', '_hash_string', '_message' (for consistency with aead functions), any other suggestions?
Regards, /Niels
Niels Möller nisse@lysator.liu.se writes:
I'm leaning towards deleting this support (leaving extra hashing to applications that need it) for Nettle-4.0, to keep things simple. It can be added back later if there are compelling use cases.
One case are the hkdf test vectors in RFC 5869, where the salt argument to HKFD-Extract is used as the hmac key, and some test vectors use an 80-byte salt, for sha256 and sha1. And also HKDF-Expand allows large prk input, even if typically it is the size of a digest.
Not clear to me if those test vectors represent a typical or reasonable use of hkdf?
But then Nettle's hkdf_extract and hkdf_expand functions don't quite match the RFC, in that they take an already initialized mac context as argument, leaving the actual hmac_*_set_key call to the application.
/Niels
On 27/05/25 05:14, Niels Möller wrote:
Simon Josefsson writes:
I've seen applications pass in human password strings into HMAC, which are sometimes longer than the block size resulting in the extra hash step. This is usually bad practice (use scrypt or argon2 instead) but exists.
I'm leaning towards deleting this support (leaving extra hashing to applications that need it) for Nettle-4.0, to keep things simple. It can be added back later if there are compelling use cases.
Perhapse a separate helper function that takes arbitrary string and converts to correct input for the new HMAC. That would be good to cover the edge cases and retain spec compliance.
void sha256_sum (uint8_t *digest, size_t length, const uint8_t *data); to hash a contiguous string without having to bother with init/update/digest? Implementation would typically need to allocate a context struct on the stack.Yes! I find such APIs really useful. Many applications create a similar one internally.
Filed https://git.lysator.liu.se/nettle/nettle/-/issues/12. Is '_sum' a good name? Some alternatives, '_hash', '_hash_string', '_message' (for consistency with aead functions), any other suggestions?
IMO, '_hash' seems right.
HTH Amos
nettle-bugs@lists.lysator.liu.se
-
Amos Jeffries -
Niels Möller -
Simon Josefsson