Subject: Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Tue, 12 May 2020 18:09:22 +0000

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 that 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 practically a pseudorandom key.

When the shared secret is shorter than the input block length of the hash function, we have:

KDK = HMAC(K, text) = H((K0 ⊕ opad )|| H((K0 ⊕ ipad) || text)).

Looking at the construction, text is hashed 2 times and K0 (key) is hashed 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 for 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ütze\"; Dang, Quynh H. (Fed)
Cc: [email-masked]
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ütze"" <[email-masked] on behalf of [email-masked]> 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 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, application specific KDFs. Of course, I can generate them by myself with an independent implementation, but I'm talking about evaluation/approval business here.

    Regards

    Torsten

    Gesendet: Dienstag, 12. Mai 2020 um 14:04 Uhr
    Von: "Dang, Quynh H. (Fed)" <[email-masked]>
    An: "Torsten Schütze" <[email-masked]>, "Hugo Krawczyk" <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    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 pseudorandom 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ütze" <[email-masked]>
    Sent: Tuesday, May 12, 2020 7:39 AM
    To: Hugo Krawczyk <[email-masked]>
    Cc: Dang, Quynh H. (Fed) <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
    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-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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 12 May 2020 18:25:57 +0000

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 – just 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’s OK to do so? Perhaps saying that in such a case K0 should be padded to full digest size if it’s shorter (thus enforcing complete digest cycle over the secret itself no matter what)?

Thanks!!

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Tuesday, May 12, 2020 at 14:10
To: Uri Blumenthal <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

Hi Uri,

Regards,

Quynh. 

Good to know, thanks!

    Hi Quynh,

    Regards 

    Torsten

    Hi Torsten,

    Regards,
    Quynh. 

    Hi Hugo, hi Quynh,

       N = ceil(L/HashLen)

       where:

    5.2 KDF in Feedback Mode

    1.  n: = \ceil{L/h}.

    Torsten

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 12 May 2020 22:33:13 -0400

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 <
[email-masked]> 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 – just 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’s OK to do so?
> Perhaps saying that in such a case K0 should be padded to full digest size
> if it’s shorter (thus enforcing complete digest cycle over the secret
> itself no matter what)?
>
>
>
> Thanks!!
>
>
>
> *From: *"Dang, Quynh H. (Fed)" <[email-masked]>
> *Date: *Tuesday, May 12, 2020 at 14:10
> *To: *Uri Blumenthal <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS
> 1.3)
>
>
>
> Hi Uri,
>
>
>
> 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 that
> 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 practically
> a pseudorandom key.
>
>
>
> 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.
>
>
>
> NIST approved the construction of HKDF because Hugo had security proof for
> 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ütze\"; Dang, Quynh H. (Fed)
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS
> 1.3)
>
>
>
> Good to know, thanks!
>
> 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ütze"" <
> [email-masked] on behalf of [email-masked]> 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 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, application specific KDFs.. Of course, I can
> generate them by myself with an independent implementation, but I'm talking
> about evaluation/approval business here.
>
>     Regards
>
>     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
>     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 pseudorandom
> 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.
>
>
>
>     Cc: Dang, Quynh H. (Fed) <[email-masked]>; [email-masked] <
> [email-masked]>; [email-masked] <[email-masked]>; [email-masked] <
> [email-masked]>
>     > 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.
>
>     "[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.
>
>     "2. Call KDF( K_DK, L, {IV,} FixedInfo ) to obtain
> DerivedKeyingMaterial or an error indicator (see [SP 800-108] for details)."
>
>     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
>
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 13 May 2020 12:51:57 +0000

>  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. 
 
I have read that paper, and did not understand the rationale. So, I’m asking to explain in plain English what are the *practical* security consequences of using Shared Secret (which is assumed to have enough entropy, but not perfectly uniformly distributed) as a key in the HKDF Extractor (HMAC), and the salt (which is assumed to be completely non-random) as the data.
 
> 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. 
 
There are assumptions about what properties the underlying hash function has, and there’s no way around it.
 
> 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.
 
Understood, in general.
 
>  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. 
 
So, if there is no random salt available (and IKM does not apply because Shared Secret is just one blob) – your analysis suggests it’s better to key HMAC with zero and input Shared Secret as HMAC data? Instead of using Shared Secret as HMAC key, and non-random domain separators (“salt” in my case) as HMAC data?
 
>  You want a different function, then you should analyze it. 
 
Thank you very much.

On Tue, May 12, 2020 at 2:26 PM Blumenthal, Uri - 0553 - MITLL <mailto:[email-masked]> wrote:
Quynh,

 
Thanks!!
 
From: "Dang, Quynh H. (Fed)" <mailto:[email-masked]>
Date: Tuesday, May 12, 2020 at 14:10
To: Uri Blumenthal <mailto:[email-masked]>
Cc: "mailto:[email-masked]" <mailto:[email-masked]>
Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
 
Hi Uri,

 

 

 

Regards,
Quynh. 

Cc: mailto:[email-masked]
 
Good to know, thanks!

On 5/12/20, 08:36, "TLS on behalf of "Torsten Schütze"" <mailto:[email-masked] on behalf of mailto:[email-masked]> 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 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, application specific KDFs.. Of course, I can generate them by myself with an independent implementation, but I'm talking about evaluation/approval business here.

    Regards 

    Torsten

    Gesendet: Dienstag, 12. Mai 2020 um 14:04 Uhr
    Von: "Dang, Quynh H. (Fed)" <mailto:[email-masked]>
    An: "Torsten Schütze" <mailto:[email-masked]>, "Hugo Krawczyk" <mailto:[email-masked]>
    Cc: "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>
    Betreff: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

    Hi Torsten,

    Regards,
    Quynh. 

    From: "Torsten Schütze" <mailto:[email-masked]>
    Sent: Tuesday, May 12, 2020 7:39 AM
    To: Hugo Krawczyk <mailto:[email-masked]>
    Cc: Dang, Quynh H. (Fed) <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>
    Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

    Hi Hugo, hi Quynh,

    > 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.

       N = ceil(L/HashLen)

       where:

    5.2 KDF in Feedback Mode

    1.  n: = \ceil{L/h}.

    Torsten

    mailto:[email-masked]
mailto:[email-masked]

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 14 May 2020 15:00:23 +0000

When the IKM is longer than 1 block, it gets hashed iteratively by the compression function in Merkle-Damgard fashion (the hash function). Then, this hashed result is padded to become a full block, then Xor with opad and ipad (making input blocks are "independent"/different blocks/keys.  One of these Xored values is hashed with the salt, then its result and the other Xored value get hashed one more time by the iterative MD-hash function. 

I dont understand why any extraction property that you get from the traditional extraction gets lost by this alternative method. 

The only way I know to justify this step in general is to assume the underlying hash function is a RO which is general is not, due to extension attacks. 

Can you please explain: what is the significance of extension attacks in this context? 

KDF is not a MAC. And while it’s nice to have a construction as generic as possible – sometimes it helps to narrow the applicability scope, because the generic version may be too limiting for that specific use case.

This would make the analysis fully dependent on RO while the analysis of HKDF can use less stringent modeling depending on particular cases.

Thank you. One conclusion I draw form this is – since extension attacks do not seem to apply/matter for the Key Derivation, it is reasonably safe to model the entire hash function as RO. Therefore, the proposed option appears to be safe.

For me, it is less important to stay generic than to be able to employ currently-available commercial HSM. For that use case, modeling hash function (even SHA-2) as RO seems OK.

I don't know how you do that if the only input to the function is an initial hash value of the IKM.

When the IKM is not more than an input block, then each of  the 2 Xored values gets processed by 1 compression function call which is modeled as a RO. I dont understand why this alternative method losses some extraction property from the traditional extraction function.

When the key is no longer than hash block then you would need to assume what the compression function is a PRF when keyed via a non-uniform key, essentially assuming what you need to prove.  

You can go ahead and use the reverse construction as an ad-hoc construction. However, if you want a detailed analysis such as in the case of HKDF , which is careful about lowering cryptographic assumptions, builds on the Merkle Damgard iterations (that are the basis of HMAC as PRF), is based on rich statistical extraction literature of 30+ years,  justifies the use of the function for many different settings (reflected very well in the use of HKDF in practical protocol, cf. TLS 1.3), and provides usage guidance, then I am not sure you can do it with the ad-hoc construction.

At the risk of repeating myself: while I appreciate what you’re explaining here, in my case staying with the lowest theoretic-proven cryptographic assumptions makes stuff undeployable in practice. 

I really recommend you read the paper.  As I said at the beginning of this thread, I don't want to convert this into an exposition on HKDF. For that I wrote a full paper

I think I said that I have read that paper (I suspect that Quynh did too), and (in my case) found it targeting a different audience. No offence meant – but if it were more readable, I wouldn’t have to ask my questions here.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 17 May 2020 05:54:54 +0000

After some private discussion with Hugo and analyzing my use case, it appears that I won’t need to reverse the HKDF inputs after all.

To recap my use case: I have an HSM with pre-loaded/pre-shared symmetric keys (of good quality). 

I need to:
  a. derive new symmetric keys from those pre-shared, using non-secret non-random input
  b. derive new symmetric keys from the output of ephemeral (asymmetric) Key Exchange

HSM doesn't directly support KDF of any kind, but supports HMAC. So my best hope for KDF is HKDF that I construct manually from the HSM-provided primitive (HMAC).

For (a) I can construct HKDF by manually invoking (this description is a simplification) HSM HMAC(key=pre-shared-key, data=my-non-random-data). That would be compliant with RFC 5869 because I'm deriving from a strong key - therefore it's OK to skip HKDF-Extract step and proceed directly to HKDF-Extract (all the HKDF security proofs apply).

For (b) I construct HKDF by manually invoking HSM HMAC(key=pre-shared-key, data=EDH-output) - with more invocations, of course, but that's the essence. In the HKDF-Extract step I'm replacing random salt (or salt of all zeroes) with a strong secret - which is even better than using random salt. Again, all the security proofs apply.

If my pre-shared keys weren't strong, the above would not work wrt. the current KHDF security assumptions & proofs.

TNX!

From: Cfrg <[email-masked]> on behalf of Uri Blumenthal <[email-masked]>

Date: Thursday, May 14, 2020 at 11:01

To: Hugo Krawczyk <[email-masked]>, "Dang, Quynh H. (Fed)" <[email-masked]>

Subject: Re: [Cfrg] [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)