Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF73A0CEF for ; Tue, 12 May 2020 19:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZiFJBuTIJDD for ; Tue, 12 May 2020 19:33:43 -0700 (PDT) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C3A3A0CE4 for ; Tue, 12 May 2020 19:33:43 -0700 (PDT) Received: by mail-ej1-f52.google.com with SMTP id s9so12897187eju.1 for ; Tue, 12 May 2020 19:33:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EsMdIxfYg29UIc4vdKAYDae6bTC01VtOAlGVIFyvff0=; b=BhOard63E7q5w4ILg6ZjqiSWOmjNV6FysdMXUDme3PILuIkzy19KyHh5IsSRYo4i6Q QOLS5Jwfb8mpv4X9Wv6WqRtf6TMlP0vPo/+sXamOxQ1mmkQU9z/w2zciMaTKve7yUkDD bC6eaWU/RBW82lyZulNgID2VSbfK+OckkYingvn5MD+CPfefOqgkO5gPuazcQO95YXxV U4vbVle6YnO6CgahHjYBxK1wHAZS7gfHKl4mfb1RkDgEOPaENiZKYW6iEFHX4a5RXRvW 5dfJCVVZdFmxJFtctFvKaPL1GPQurbrLY6hGKv3SqIV+U1GeJ9uTdpqF2wJngKl53yTJ /RRg== X-Gm-Message-State: AGi0PuaDlDfUfxJG2C5UqQrSvwnRAI5t/gXB4jpLrLDQn7FNwpuKpIIT HD1Ku3LKLqe6ecHIZomsPcx9O4LZK71I3r/+dgti/2O0 X-Google-Smtp-Source: APiQypIIT/efxLh0n9AMrYapgfpafD/3ZNE+vl15eZwQM4mcjppDDk83/orpBfNB0qXkEtJoz4QWNRbvGm04P4tfre8= X-Received: by 2002:a17:906:6453:: with SMTP id l19mr15762270ejn.169.1589337221604; Tue, 12 May 2020 19:33:41 -0700 (PDT) MIME-Version: 1.0 References: <24CF244F-83C8-4771-9E37-B851DC5013BC@ll.mit.edu> In-Reply-To: <24CF244F-83C8-4771-9E37-B851DC5013BC@ll.mit.edu> From: Hugo Krawczyk Date: Tue, 12 May 2020 22:33:13 -0400 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: "Dang, Quynh H. (Fed)" , "cfrg@ietf.org" Content-Type: multipart/alternative; boundary="00000000000085a7e305a57e6899" Archived-At: Subject: Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3) X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 02:33:46 -0000 --00000000000085a7e305a57e6899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I really don't want to transform this into an exposition on HKDF and its design rationale. I refer anyone interested to the paper where this rationale is presented in detail. The analysis in the paper does not apply to the function where the IKM and salt are reversed. When you think about the underlying hash function as a magic function that will do anything you ask it to do then all type of constructions seem to work. The effort in HKDF was to create a single function that works well in a variety of practical settings backed by analysis that tries to minimize reliance on the magic of the hash functions as much as possible. The guidance provided in the HKDF RFC 5869 (use of random salt or 0 otherwise, independent values of IKM, etc) is not arbitrary but based on such analysis. You want a different function, then you should analyze it. Hugo On Tue, May 12, 2020 at 2:26 PM Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > Quynh, > > > > Thank you! So, you also do not see a problem with reversing salt and > shared secret in the KHDF input, right? (Sorry for re-stating =E2=80=93 j= ust want > to make absolutely and explicitly sure.) > > > > Is there any way NIST would *officially* permit such a modification, > i.e., add a statement in the -56Cr2 that when needed it=E2=80=99s OK to d= o so? > Perhaps saying that in such a case K0 should be padded to full digest siz= e > if it=E2=80=99s shorter (thus enforcing complete digest cycle over the se= cret > itself no matter what)? > > > > Thanks!! > > > > *From: *"Dang, Quynh H. (Fed)" > *Date: *Tuesday, May 12, 2020 at 14:10 > *To: *Uri Blumenthal > *Cc: *"cfrg@ietf.org" > *Subject: *Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS > 1.3) > > > > Hi Uri, > > > > NIST's specification in SP 800-56C does not allow the reversed order of > the input: shared secret and salt. > > > > When treating the shared secret as the key in HMAC, if it is longer than > the input block of the hash function, then it gets hashed first. When th= at > happens, the resulted/hashed key is practically/almost a pseudorandom key > if the hash function is a good hash function. So, I would not worry much > in this case because it would be as a HMAC-KDF when the key is practicall= y > a pseudorandom key. > > > > When the shared secret is shorter than the input block length of the hash > function, we have: > > > > KDK =3D HMAC(K, text) =3D H((K0 =E2=8A=95 opad )|| H((K0 =E2=8A=95 ipad) = || text)). > > > > Looking at the construction, text is hashed 2 times and K0 (key) is hashe= d > at 2 places then another hash on top. > > > > The current extraction step has the shared secret as the message (text) > and the salt as the key. So, the shared secret is hashed 2 times (nested > fashion). > > > > When you reverse the input order: the shared secret as the key, then the > shared secret gets hashed at 2 places where those 2 input to the hash > function are different (due to opad and ipad), then another hash on top > (nested fashion) (total: 3 hashes). So, I don't see a problem with this. > > > > Remember: this discussion is a few minutes of looking at HMAC's > construction. > > > > You should ask Hugo for better insights and security analysis and proof(s= ). > > > > NIST approved the construction of HKDF because Hugo had security proof fo= r > it and it was accepted at Crypto and we believed in its security. > > > > Regards, > > Quynh. > > > > > > > ------------------------------ > > *From:* Blumenthal, Uri - 0553 - MITLL > *Sent:* Tuesday, May 12, 2020 12:02 PM > *To:* "Torsten Sch=C3=BCtze\"; Dang, Quynh H. (Fed) > *Cc:* cfrg@ietf.org > *Subject:* Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS > 1.3) > > > > Good to know, thanks! > > Could you clarify, please: does this "permission to permute" apply to the > input to the HKDF extractor as well? > > SP800-56Cr2 section 5 "Two-Step Key Derivation" (3rd paragraph) requires > that "salt" serves as a MAC *key*, and the shared secret Z serves as the > "message". I need to reverse these, because HSM devices that do not > directly implement HKDF cannot run HMAC in this mode. > > If what I'm asking is not allowed - can you please explain why from a > *practical* cryptography point of view (and given that the "salt" is > neither random nor uniformly distributed)? I.e., what would break or what > attacks would become possible? > > > On 5/12/20, 08:36, "TLS on behalf of "Torsten Sch=C3=BCtze"" < > tls-bounces@ietf.org on behalf of Torsten.Schuetze@gmx.net> wrote: > > Hi Quynh, > > thank you for your quick response. I knew that omitting some fields > was allowed, but not that permutations are allowed, too. Okay, this makes > HKDF RFC 5869 definitely to a NIST SP800-56C rev 2 compliant KDF. But wha= t > to do about the CAVP tests or approved test vectors.. Couldn't NIST provi= de > for the very often used RFC 5869 HKDF approved test vectors? I coulnd't > find any. Only for some older, application specific KDFs.. Of course, I c= an > generate them by myself with an independent implementation, but I'm talki= ng > about evaluation/approval business here. > > Regards > > Torsten > > > Gesendet: Dienstag, 12. Mai 2020 um 14:04 Uhr > Von: "Dang, Quynh H. (Fed)" > An: "Torsten Sch=C3=BCtze" , "Hugo Krawczyk= " < > hugo@ee.technion.ac.il> > Cc: "cfrg@ietf.org" , "tls@ietf.org" , " > rsalz@akamai.com" > Betreff: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3= ) > > Hi Torsten, > > Thank you for the review. I think the review helps many people to > understand the HKDF's spec and its NIST's approval better. > > In SP 800-108 ( > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108= .pdf, > at the end of Section 5. (before 5.1), it says that " Alternative orders > for the input data fields may be used > for different KDFs. " . > > And, at the end of the paragraph before that, it says "One or more of > these fixed input data fields may be omitted unless required for > certain purposes as discussed in Section 7.5 and Section 7.6.". > > After an extraction step, the output is a pseudorandom key. The KDFs > in SP 800-108 are NIST's approved KDFs to derive key(s) from a pseudorand= om > key. The purpose of any of these KDFs in SP 800-108 is the same with the > purpose of the expansion step. Therefore, they are allowed for being used > as expansion steps. > > Regards, > Quynh. > > > > ------------------------------------------------------------ > > From: "Torsten Sch=C3=BCtze" > Sent: Tuesday, May 12, 2020 7:39 AM > To: Hugo Krawczyk > Cc: Dang, Quynh H. (Fed) ; cfrg@ietf.org < > cfrg@ietf.org>; tls@ietf.org ; rsalz@akamai.com < > rsalz@akamai.com> > Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3= ) > > > 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-expansio= n > 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 =3D ceil(L/HashLen) > T =3D T(1) | T(2) | T(3) | ... | T(N) > OKM =3D first L octets of T > > where: > T(0) =3D empty string (zero length) > T(1) =3D HMAC-Hash(PRK, T(0) | info | 0x01) > T(2) =3D HMAC-Hash(PRK, T(1) | info | 0x02) > T(3) =3D 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: =3D \ceil{L/h}. > 2. If n > 2^{32} -1, then indicate an error and stop. > 3. result(0):=3D =E2=88=85 and K(0):=3D IV. > 4. For i =3D 1 to n, do > a. > K(i) :=3D PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Conte= xt > || [L]2) > b. > result(i) :=3D result(i-1) || K(i) > 5.. Return: K_O :=3D the leftmost L bits of result(n). > > With the substitutions PRK =3D KI, HashLen =3D h, N =3D n, T(i) =3D K= (i-1) > 0x01, 0x02 =3D [i]_2, PKM =3D K_O and info =3D Label || 0x00 || Context |= | [L]_2 > one is almost there, EXCEPT > > - the counter 0x01, 0x02, 0x03 is at the end of the string in HKDF RF= C > 5869 and right-after the K(i-1), respectively T(i), in SP800-108. At leas= t > 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 =3D 255 as L \le 2= 55 > 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-25= 6 > 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 =3D 255. BTW, I don't h= ave > 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 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --00000000000085a7e305a57e6899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I really don't wan= t to transform this into an exposition on HKDF and its design rationale. I = refer anyone interested to the paper where this rationale is presented in d= etail. The analysis in the paper does not apply to the function where the I= KM and salt are reversed. When you think about the underlying hash function= as a magic function that will do anything you ask it to do then all type o= f constructions seem to work. The effort in HKDF was to create a single fun= ction that works well in a variety of practical settings backed by analysis= that tries to minimize reliance on the magic of the hash functions as much= as=C2=A0possible. The guidance provided in the HKDF RFC 5869 (use of rando= m salt or 0 otherwise, independent values of IKM, etc)=C2=A0 is not arbitra= ry but based on such analysis. You want a different function, then you shou= ld analyze it.=C2=A0

Hugo=C2=A0

On Tue, May 12, 2020 at 2:26 PM Blumenthal, Uri - 0553 - MI= TLL <uri@ll.mit.edu<= /a>> wrote:
<= div lang=3D"EN-US">

Quynh,

=C2=A0

Thank you= !=C2=A0 So, you also do not see a problem with reversing salt and shared se= cret in the KHDF input, right? (Sorry for re-stating =E2=80=93 just want to= make absolutely and explicitly sure.)

=C2=A0

Is there any way NIST wo= uld officially permit such a modification, i.e., add a statement in = the -56Cr2 that when needed it=E2=80=99s OK to do so? Perhaps saying that i= n such a case K0 should be padded to full digest size if it=E2=80=99s short= er (thus enforcing complete digest cycle over the secret itself no matter w= hat)?

=C2=A0

Thanks!!

= =C2=A0

From: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
Date: Tuesday, Ma= y 12, 2020 at 14:10
To: Uri Blumenthal <uri@ll.mit.edu>
Cc: "cfrg@ietf.org" &l= t;cfrg@ietf.org><= br>Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefo= re TLS 1.3)

=C2=A0

Hi Uri,

= =C2=A0

NIST's specificat= ion in SP 800-56C does not allow the reversed order of the input: shared se= cret and salt.

=C2=A0

When treating the sh= ared secret as the key in HMAC, if it is longer than the input block of the= hash function, then it gets hashed first.=C2=A0 When that happens, the res= ulted/hashed key is practically/almost a pseudorandom key if the hash funct= ion is a good hash function.=C2=A0 So, I would not worry much in this case = because it would be as a HMAC-KDF when the key is practically a pseudorando= m key.=C2=A0

= =C2=A0

When the shared secre= t is shorter than the input block length of the hash function, we have:=C2= =A0

=C2=A0<= /u>

KDK =3D HMAC(K, text) =3D H((K0 =E2=8A=95 opad )|| H((K0 =E2=8A=95 ipad) || text)).=C2=A0=

=C2=A0

Looking at the construction, text is hashed 2 times and K0 (ke= y) is hashed at 2 places then another hash on top.=C2=A0

<= /div>

=C2=A0

The current extraction step has the shared secret as the me= ssage (text) and the salt as the key. So, the shared secret is hashed 2 tim= es (nested fashion).=C2=A0

=C2=A0

When you reverse the input order= : the shared secret as the key, then the shared secret gets hashed at 2 pla= ces where those 2 input to the hash function are different (due to opad and= ipad), then another hash on top (nested fashion) (total: 3 hashes). So, I = don't see a problem with this.

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-left:0.5in">Remember: this discussion= is a few minutes of looking at HMAC's construction.=C2=A0=C2=A0=

=C2=A0

You should ask Hugo for better insights and security analysis and = proof(s).

=C2=A0

NIST approved the construction of HKDF because Hug= o had security proof for it and it was accepted at Crypto and we believed i= n its security.=C2=A0

=C2=A0

Regards,

<= p class=3D"MsoNormal" style=3D"margin-left:0.5in">Quynh.=C2=A0

= =C2=A0

=C2=A0

=C2=A0=

<= hr size=3D"0" width=3D"100%" align=3D"center">

From: Blumentha= l, Uri - 0553 - MITLL
Sent: Tuesday, May 12, 2020 12:02 PM
= To: "Torsten Sch=C3=BCtze\"; Dang, Quynh H. (Fed)
Cc: cfrg@ietf.org
= Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore = TLS 1.3)

=C2=A0<= /u>

Good to know, thanks!

Could you clarify, please: does th= is "permission to permute" apply to the input to the HKDF extract= or as well?

SP800-56Cr2 section 5 "Two-Step Key Derivation"= ; (3rd paragraph) requires that "salt" serves as a MAC *key*, and= the shared secret Z serves as the "message". I need to reverse t= hese, because HSM devices that do not directly implement HKDF cannot run HM= AC in this mode.

If what I'm asking is not allowed - can you ple= ase explain why from a *practical* cryptography point of view (and given th= at the "salt" is neither random nor uniformly distributed)? I.e.,= what would break or what attacks would become possible?


On 5/12= /20, 08:36, "TLS on behalf of "Torsten Sch=C3=BCtze"" &= lt;tls-bounces@ie= tf.org on behalf of Torsten.Schuetze@gmx.net> wrote:

=C2=A0=C2=A0=C2= =A0 Hi Quynh,

=C2=A0=C2=A0=C2=A0 thank you for your quick response. = I knew that omitting some fields was allowed, but not that permutations are= allowed, too. Okay, this makes HKDF RFC 5869 definitely to a NIST SP800-56= C rev 2 compliant KDF. But what to do about the CAVP tests or approved test= vectors.. Couldn't NIST provide for the very often used RFC 5869 HKDF = approved test vectors? I coulnd't find any. Only for some older, applic= ation specific KDFs.. Of course, I can generate them by myself with an inde= pendent implementation, but I'm talking about evaluation/approval busin= ess here.

=C2=A0=C2=A0=C2=A0 Regards

=C2=A0=C2=A0=C2=A0 Tors= ten


=C2=A0=C2=A0=C2=A0 Gesendet: Dienstag, 12. Mai 2020 um 14:04= Uhr
=C2=A0=C2=A0=C2=A0 Von: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov&= gt;
=C2=A0=C2=A0=C2=A0 An: "Torsten Sch=C3=BCtze" <Torsten.Schuetze@gmx= .net>, "Hugo Krawczyk" <hugo@ee.technion.ac.il>
=C2=A0=C2=A0= =C2=A0 Cc: "cfrg@ie= tf.org" <cfr= g@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "rsalz@akamai.com" <rsalz@akamai.com>
=C2=A0=C2=A0=C2=A0 Betref= f: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

=C2= =A0=C2=A0=C2=A0 Hi Torsten,

=C2=A0=C2=A0=C2=A0 Thank you for the rev= iew. I think the review helps many people to understand the HKDF's spec= and its NIST's approval better.

=C2=A0=C2=A0=C2=A0 In SP 800-1= 08 (https://nvlpubs.nist.gov/nistpubs/Lega= cy/SP/nistspecialpublication800-108.pdf, at the end of Section 5. (befo= re 5.1), it says that "=C2=A0 Alternative orders for the input data fi= elds may be used
=C2=A0=C2=A0=C2=A0 for different KDFs. " .

= =C2=A0=C2=A0=C2=A0 And, at the end of the paragraph before that, it says &q= uot;One or more of these fixed input data fields may be omitted unless requ= ired for
=C2=A0=C2=A0=C2=A0 certain purposes as discussed in Section 7.5= and Section 7.6.".

=C2=A0=C2=A0=C2=A0 After an extraction step= , the output is a pseudorandom key. The KDFs in SP 800-108 are NIST's a= pproved KDFs to derive key(s) from a pseudorandom key.=C2=A0 The purpose of= any of these KDFs in SP 800-108 is the same with the purpose of the expans= ion step. Therefore, they are allowed for being used as expansion steps.
=C2=A0=C2=A0=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0 Quynh.


=
=C2=A0=C2=A0=C2=A0 ----------------------------------------------------= --------

=C2=A0=C2=A0=C2=A0 From: "Torsten Sch=C3=BCtze" &= lt;Torsten.Sc= huetze@gmx.net>
=C2=A0=C2=A0=C2=A0 Sent: Tuesday, May 12, 2020 7:= 39 AM
=C2=A0=C2=A0=C2=A0 To: Hugo Krawczyk <hugo@ee.technion.ac.il>
=C2=A0= =C2=A0=C2=A0 Cc: Dang, Quynh H. (Fed) <quynh.dang@nist.gov>; cfrg@ietf.org <cfrg@ietf.org>; tls@ietf.org <tls@ietf.org>; rsalz@akamai.com <rsalz@akamai.com>
=C2=A0=C2=A0=C2=A0 Su= bject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

=C2=A0=C2=A0=C2=A0 Hi Hugo, hi Quynh,

=C2=A0=C2=A0=C2=A0 on Mon= day, 2020-05-11 Hugo Krawzcyk wrote:

=C2=A0=C2=A0=C2=A0 > I have= n'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 complian= t with the NIST recommendation. It would be nice if this time it would make= very explicit that RFC 5869 is compliant with this Recommendation.

= =C2=A0=C2=A0=C2=A0 Indeed. In SP800-56C Rev. 2 draft we have in lines 545, = 546:

=C2=A0=C2=A0=C2=A0 "[RFC 5869] specifies a version of the = above extraction-then-expansion key-derivation procedure using HMAC for bot= h the extraction and expansion steps."=C2=A0 so one would assume that = HKDF according to RFC 5869 is compliant with SP800-56CR2.

=C2=A0=C2= =A0=C2=A0 However, for key expansion it refers in line 533, 532 to

= =C2=A0=C2=A0=C2=A0 "2. Call KDF( K_DK, L, {IV,} FixedInfo ) to obtain = DerivedKeyingMaterial or an error indicator (see [SP 800-108] for details).= "

=C2=A0=C2=A0=C2=A0 Everything would be fine if we find KDF( K= _DK, L, {IV}, FixedInfo) as

=C2=A0=C2=A0=C2=A0 HKDF-Expand(PRK, info= , L) -> OKM

=C2=A0=C2=A0=C2=A0 The output OKM is calculated as fo= llows:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 N =3D ceil(L/HashLen)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T =3D T(1) | T(2) | T(3) | ... | T(N)=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OKM =3D first L octets of T
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where:
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 T(0) =3D empty string (zero length)
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 T(1) =3D HMAC-Hash(PRK, T(0) | info | 0x01)
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 T(2) =3D HMAC-Hash(PRK, T(1) | info | 0x02)
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T(3) =3D HMAC-Hash(PRK, T(2) | info | 0x03)<= br>
=C2=A0=C2=A0=C2=A0 i.e. the definitions of RFC 5869 in SP800-108. Un= fortunately, the closest one could find in SP800-108 is

=C2=A0=C2=A0= =C2=A0 5.2 KDF in Feedback Mode

=C2=A0=C2=A0=C2=A0 1.=C2=A0 n: =3D \= ceil{L/h}.
=C2=A0=C2=A0=C2=A0 2.=C2=A0 If n > 2^{32} -1, then indicat= e an error and stop.
=C2=A0=C2=A0=C2=A0 3.=C2=A0 result(0):=3D =E2=88=85 and K(0)= :=3D IV.
=C2=A0=C2=A0=C2=A0 4.=C2=A0 For i =3D 1 to n, do
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K(i) :=3D PRF (KI, K(i-1) {|| [i]2 }|| La= bel || 0x00 || Context || [L]2)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 b.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 result(i) :=3D result(i-1) || K(i)
=C2=A0=C2=A0=C2=A0 5.. Return: K_= O :=3D the leftmost L bits of result(n).

=C2=A0=C2=A0=C2=A0 With the= substitutions PRK =3D KI, HashLen =3D h, N =3D n, T(i) =3D K(i-1) 0x01, 0x= 02 =3D [i]_2, PKM =3D K_O and info =3D Label || 0x00 || Context || [L]_2 on= e is almost there, EXCEPT

=C2=A0=C2=A0=C2=A0 - the counter 0x01, 0x0= 2, 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 result= s. (This is what already Dan Brown wrote in a recent mail). I don't thi= nk this has security implications, but I'm no expert.

=C2=A0=C2= =A0=C2=A0 - With HKDF, it is only allowed to iterate up to N =3D 255 as L \= le 255 HashLen while in SP800-108 we have n \le 2^{32}-1.

=C2=A0=C2= =A0=C2=A0 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 c= ouldn't find any official CAVP test vectors for such an HKDF-HMAC-SHA-2= 56 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 se= curity levels. As a practitioner I would first test my HKDF RFC 5869 implem= entation if it is allows to iterate above N =3D 255. BTW, I don't have = a good feeling with extracting up to 2^{32}-1 keys from a single IKM.
=C2=A0=C2=A0=C2=A0 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 impo= rtant component, i.e. key expansion, to another, quite old document.
=C2=A0=C2=A0=C2=A0 Torsten

=C2=A0=C2=A0=C2=A0 _____________________= __________________________
=C2=A0=C2=A0=C2=A0 TLS mailing list
=C2=A0= =C2=A0=C2=A0 TLS@ietf.org=
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--00000000000085a7e305a57e6899--