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. 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. 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
