There is no flaw if you use HMAC and HKDF as intended. See details below. The bottom line advise is: If you are using related (not random) salt values in HKDF, you are probably using it with domain separation functionality. In HKDF, domain separation is enforced via the info field not the salt. Read the HKDF RFC and paper for background and rationale.
More below. On Mon, May 11, 2020 at 1:19 PM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > I will forward this to the official comment address as well. > > I don't support making HKDF a NIST standard in its current form because > there is a flaw. > > Consider the case in which the initial keying material is formed by > concatenating two items, the second of which is a variable length string. > > As currently specified, the values for o_key and i_key are the same for a > key k and that same key with a zero byte concatenated. This might not seem > like a big deal but the whole point of defining common building blocks for > crypto is to eliminate all the bear traps we can. > I assume that by o_key and i_key you mean the key xor-ed with opad and ipad, respectively. Is that right? It is true that in HMAC, and then in HKDF, you do not distinguish between a key K shorter than a block and the same key with appended 0s. This is OK in HMAC because as a MAC or PRF you must use HMAC with random keys for which the probability to have the above property (choosing two keys of different lengths, one being the prefix of the other) is virtually 0. For HKDF, this issue applies to the salt value. Salt values (read the RFC) should either be random or set to the all-zero string. Hence no issue there. You can read the HKDF paper for extensive rationale for these choices. https://eprint.iacr.org/2010/264 > The problem can be eliminated as follows: > > 1) Generate i_key by padding the key value with byte x before XORing with > the i_mask > > 2) Generate o_key by padding the key value with byte y (y <> x) before > XORing with the o_mask > > This ensures that the values of o_key and i_key will change if zeros are > appended. > It will not solve the issue if one of the keys is of a block length Historical anecdote: The original design of HMAC had the concatenation scheme as you suggest, Adi Shamir suggested changing it to xoring method that was eventually adopted (see the Acknowledgment section in the HMAC 1996 paper), https://link.springer.com/content/pdf/10.1007/3-540-68697-5_1.pdf So you can see that thought was put into these issues. > > This would require us to issue a revised version of HKDF. But I think we > should do just that. Crypto utility functions should be robust under all > known forms of mistreatment. I am probably not the only person who has > multiple salt inputs to a KDF. Fortunately my unit tests caught the issue. > You should not have multiple salt inputs if they are not independently random. If you want to use them for "domain separation", use the info field. _______________________________________________ > Cfrg mailing list > c...@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
