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
