ni...@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, -- Daiki Ueno _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
