3 ms·

HMAC-SHA256 is a secure and conservative choice for almost any application, but allows a variable key size. I'm sure I've seen deployments with a 0 bit key. Mo

by tveita 10y ago

HMAC-SHA256 is a secure and conservative choice for almost any application, but allows a variable key size. I'm sure I've seen deployments with a 0 bit key. Most algorithms in use happen to be defined only for a 128 bit symmetric key or above, which is also the currently recommended key length, but that is incidental. There is no fundamental truth in your quote, it has been wrong in the past, and it will be wrong in the future.

tptacek 10y ago
SHA-2 is a great example of what I'm talking about. The best SHA-2's to use don't have the highest output size. w/r/t/ variable-sized HMAC key sizes: you don't need to "select" a key size, so much as you want it ideally to be harmonized with the key size of your cipher. Since you're going to use AES-128 anyways, this isn't a tricky decision.
- tveita 10y ago
  You said key size does not matter. This post doesn't seem to relate to that at all.
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 ago
  KMAC 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...

by tveita 10y ago

tptacek 10y ago

SHA-2 is a great example of what I'm talking about. The best SHA-2's to use don't have the highest output size. w/r/t/ variable-sized HMAC key sizes: you don't need to "select" a key size, so much as you want it ideally to be harmonized with the key size of your cipher. Since you're going to use AES-128 anyways, this isn't a tricky decision.

tveita 10y ago
You said key size does not matter. This post doesn't seem to relate to that at all.

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 ago
KMAC 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...