2 ms·
That's not really fair to say. The HMAC RFC[1] explicitly discourages key sizes of less than L bytes, which in context is about 128 bits. Variable key sizes can
by dsacco 10y ago
That's not really fair to say. The HMAC RFC[1] explicitly discourages key sizes of less than L bytes, which in context is about 128 bits. Variable key sizes can be chosen, sure, but it's not exactly a feature if there is an implicit lower bound.
I would say it is a fault of the HMAC construction that any key size can be selected, not a fault of using a key size HMAC is not designed for. An improvement would be explicitly defined key sizes that are compatible with other algorithms in an entire cryptosystem. If HMAC were to be built from scratch today, it would probably be better to have explicitly defined key sizes instead of variable key sizes.
I know this might come across as obtuse or stubborn, but if you read the other comment I made in this thread I think it might clarify my point.
[1]: https://tools.ietf.org/html/rfc2104#section-3 https://tools.ietf.org/html/rfc2104#section-3
- tveita 10y agoKMAC is a proposed new MAC standard based on the Shake function used in SHA-3. It explicitly is defined for all key sizes: "K is the key, a byte string of any length. An empty string is a legal input." It has some guidance about choosing a secure key size but ultimately libraries are likely to handle this the exact same way as with HMAC and allow users shoot themselves in the foot. You can call it a "fault of the construction" if you'd like, but ultimately this is a secure construction that happens to allow insecure key sizes. You'll need to use it with a secure key size, or even better, use a library where someone has chosen the key size for you. It is not something you should need to think about as an end user, but it matters. https://www.ietf.org/mail-archive/web/saag/current/pdfxrzR9rycq3.pdf https://www.ietf.org/mail-archive/web/saag/current/pdfxrzR9r...