Hi Hugo, hi Quynh, on Monday, 2020-05-11 Hugo Krawzcyk wrote: > I haven't looked at the revisions. But in previous versions you needed lawyer > skills to go through the language to see that RFC 5869 was indeed compliant > with the NIST recommendation. It would be nice if this time it would make > very explicit that RFC 5869 is compliant with this Recommendation. Indeed. In SP800-56C Rev. 2 draft we have in lines 545, 546:
"[RFC 5869] specifies a version of the above extraction-then-expansion key-derivation procedure using HMAC for both the extraction and expansion steps." so one would assume that HKDF according to RFC 5869 is compliant with SP800-56CR2. However, for key expansion it refers in line 533, 532 to "2. Call KDF( K_DK, L, {IV,} FixedInfo ) to obtain DerivedKeyingMaterial or an error indicator (see [SP 800-108] for details)." Everything would be fine if we find KDF( K_DK, L, {IV}, FixedInfo) as HKDF-Expand(PRK, info, L) -> OKM The output OKM is calculated as follows: N = ceil(L/HashLen) T = T(1) | T(2) | T(3) | ... | T(N) OKM = first L octets of T where: T(0) = empty string (zero length) T(1) = HMAC-Hash(PRK, T(0) | info | 0x01) T(2) = HMAC-Hash(PRK, T(1) | info | 0x02) T(3) = HMAC-Hash(PRK, T(2) | info | 0x03) i.e. the definitions of RFC 5869 in SP800-108. Unfortunately, the closest one could find in SP800-108 is 5.2 KDF in Feedback Mode 1. n: = \ceil{L/h}. 2. If n > 2^{32} -1, then indicate an error and stop. 3. result(0):= ∅ and K(0):= IV. 4. For i = 1 to n, do a. K(i) := PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2) b. result(i) := result(i-1) || K(i) 5. Return: K_O := the leftmost L bits of result(n). With the substitutions PRK = KI, HashLen = h, N = n, T(i) = K(i-1) 0x01, 0x02 = [i]_2, PKM = K_O and info = Label || 0x00 || Context || [L]_2 one is almost there, EXCEPT - the counter 0x01, 0x02, 0x03 is at the end of the string in HKDF RFC 5869 and right-after the K(i-1), respectively T(i), in SP800-108. At least this gives different results. (This is what already Dan Brown wrote in a recent mail). I don't think this has security implications, but I'm no expert. - With HKDF, it is only allowed to iterate up to N = 255 as L \le 255 HashLen while in SP800-108 we have n \le 2^{32}-1. So, with this interpretation I don't see that HKDF RFC5869 is a concrete instantiation of SP800-56C rev2 draft + SP800-108. At least I couldn't find any official CAVP test vectors for such an HKDF-HMAC-SHA-256 construct. BTW, while we have such test vectors in RFC 5869 for SHA-384 (and SHA-1) there are no such things for SHA-384 or SHA-512, i.e. higher security levels. As a practitioner I would first test my HKDF RFC 5869 implementation if it is allows to iterate above N = 255. BTW, I don't have a good feeling with extracting up to 2^{32}-1 keys from a single IKM. I would like to hear from NIST if there are any plans to provide CAVP test vectors for HKDF-HMAC-SHA-2 according to RFC 5869. In my opinion, SP800-56C rev2 draft is suboptimal as it refers for a very important component, i.e. key expansion, to another, quite old document. Torsten _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls