Hello,
In testutils.h, there is a nettle-meta definition for MACs, similar to hashes and ciphers:
/* FIXME: When interface stabilizes, move to nettle-meta.h */ struct nettle_mac { const char *name;
/* Size of the context struct */ unsigned context_size;
/* Size of digests */ unsigned digest_size;
/* Suggested key size; other sizes are sometimes possible. */ unsigned key_size;
nettle_set_key_func *set_key; nettle_hash_update_func *update; nettle_hash_digest_func *digest; };
This is, however, not usable for HMAC, because Nettle build uses -Wcast-function-type and the set_key member has an incompatible type with hmac_*_set_key, which requires a key length argument as HMAC allows arbitrary key length up to the hash block size.
Is there any plan to make it more generic and eventually move it to nettle-meta.h? That would be particularly useful in applications passing around HMAC functions (e.g., HKDF, deterministic ECDSA).
For example, I'm thinking to use nettle_hash_update_func for set_key and provide a wrapper around other MACs which don't take key length, something like:
void _cmac_aes128_set_key(struct cmac_aes128_ctx *ctx, size_t length, const uint8_t *key) { assert (length == AES128_KEY_LENGTH); cmac_aes128_set_key (ctx, length, key); }
Regards,
Daiki Ueno ueno@gnu.org writes:
This is, however, not usable for HMAC, because Nettle build uses -Wcast-function-type and the set_key member has an incompatible type with hmac_*_set_key, which requires a key length argument as HMAC allows arbitrary key length up to the hash block size.
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?
Is there any plan to make it more generic and eventually move it to nettle-meta.h? That would be particularly useful in applications passing around HMAC functions (e.g., HKDF, deterministic ECDSA).
If we can find a reasonable "generic" interface, yes.
For example, I'm thinking to use nettle_hash_update_func for set_key and provide a wrapper around other MACs which don't take key length, something like:
void _cmac_aes128_set_key(struct cmac_aes128_ctx *ctx, size_t length, const uint8_t *key) { assert (length == AES128_KEY_LENGTH); cmac_aes128_set_key (ctx, length, key); }
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 ?
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?
Regards, /Niels
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,
nettle-bugs@lists.lysator.liu.se
-
Daiki Ueno -
nisse＠lysator.liu.se