Ordering of Shared Secrets in SP 800-56C Combiner

[Robinson, Angela Y. (Fed)]

Dear All,

 

The key-derivation methods described in NIST SP 800-56C are currently only applicable to shared secrets established during a key establishment scheme as specified in NIST SP 80056A or 800-56B, or to Z = Z’||T which is the combination of shared secret Z’ that was generated as specified in SP 800-56A or -56B with another shared secret T that is generated in any way.  As previously stated, NIST intends to allow all key-derivation methods in NIST SP 800-56C to apply to the outputs of the ML-KEM key establishment scheme specified in FIPS 203.

 

Further, NIST intends to allow the 800-56C key derivation methods to apply to shared secrets of the form Z = T || Z’, where T and Z’ are as described above but in reverse order.  That is, we will ensure that either order is allowed for FIPS validation in upcoming revisions to -56C.  Note, however, that the order of the shared secrets will need to be specified at the protocol level to avoid confusion.  We are working on guidance to ensure that this reordering will not introduce security vulnerabilities.  NIST is open to feedback on the matter.

 

 

Angela

NIST PQC

[Kris Kwiatkowski]

Great,

Thank you Angela, that is definitely a good news for protocol designers.

Kind regards,
Kris

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB797555BA77527376183DDF1C8E202%40CO6PR09MB7975.namprd09.prod.outlook.com.

[Mike Ounsworth]

Thank you Angela! This is excellent!

 

 

> We are working on guidance to ensure that this reordering will not introduce security vulnerabilities.  NIST is open to feedback on the matter.

 

I will put my thinking into writing so that others may comment on it.

 

My understanding is that KDF(T || Z || …) is a security concern when T is completely uncontrolled … ie content and length are completely controlled by the attacker. In particular, the lowest common denominator allowed by SP 800-56Cr2 is the One-Pass (section 4) Option 1 with a single iteration of SHA2 as the KDF, but that stronger KDFs such as HMAC-SHA2 or SHA3 do not suffer from these attacks (though I am not exactly certain what the attack here is). You need some “guardrails”. Some ideas that I have heard: Disallow bare SHA2 in this reversed construction. Require applications to length-tag the input. Only allow the reversed construction when T is “well behaved” for some definition of “well behaved” (fixed-length is probably sufficient).

 

If there are other security implications here, it would be helpful to put them on the list so that multiple minds can work on the problem.

 

---

Mike Ounsworth

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5cc283ef-a216-4949-a8d9-30a4c66e035f%40amongbytes.com.

[John Mattsson]

Hi,

As many systems will use hybrid shared secrets consisting of more than two parts, I would suggest that NIST allow hybrid shared secrets of the form , where and auxiliary shared secrets. should be secure for all KDFs with acceptable security properties. I believe that hybrid shared secrets consisting of more than two parts will be relatively common. The Swedish NCSA recommends using hybrid keying combining symmetric keying, post-quantum secure asymmetric keying, and classically secure asymmetric keying [1]. Both TLS 1.3 and IKEv2 support hybrid keying with three parts or more (even if they might not align with 800-56C).

As Mike says, for KDFs with weak security properties, allowing long controlled by the attacker might create security vulnerabilities. I think NIST should deprecate weak KDFs, such as KDF(x) = SHA-2(x), and put reasonable length limits on . There is no reason to allow megabyte sized . It is good that 800-56C already requires that “method used to generate must be known and agreed upon by all parties”.

[1] On factoring integers, and computing discrete logarithms and orders, quantumly
http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf <http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf>

Cheers,
John Preuß Mattsson
Expert Cryptographic Algorithms and Security Protocols, Ericsson

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov <mailto:pqc-forum+...@list.nist.gov>.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB797555BA77527376183DDF1C8E202%40CO6PR09MB7975.namprd09.prod.outlook.com <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CO6PR09MB797555BA77527376183DDF1C8E202*40CO6PR09MB7975.namprd09.prod.outlook.com?utm_medium=email&amp;utm_source=footer__;JQ!!FJ-Y8qCqXTj2!aRGMk43n-GBo4cCAj_U47olM-j3ZMG1wptw_rdIFEhRLK1S4-_RNZyxS2wYbOQLNVjoTEO5xkF9I1R6OfDAbolcRoA$>.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov <mailto:pqc-forum+...@list.nist.gov>.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5cc283ef-a216-4949-a8d9-30a4c66e035f%40amongbytes.com <https://urldefense.com/v3/__https:/groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5cc283ef-a216-4949-a8d9-30a4c66e035f*40amongbytes.com?utm_medium=email&amp;utm_source=footer__;JQ!!FJ-Y8qCqXTj2!aRGMk43n-GBo4cCAj_U47olM-j3ZMG1wptw_rdIFEhRLK1S4-_RNZyxS2wYbOQLNVjoTEO5xkF9I1R6OfDBOfWPgbQ$>.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov <mailto:pqc-forum+...@list.nist.gov>.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB57397B7D390B81010AAEA9339F212%40CH0PR11MB5739.namprd11.prod.outlook.com <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB57397B7D390B81010AAEA9339F212%40CH0PR11MB5739.namprd11.prod.outlook.com?utm_medium=email&amp;utm_source=footer>.

[John Mattsson]

Seems like some parts of the message disappeared after I pressed send… Here is a ASCII version of the missing part:

We welcome NIST’s plans [3] to allow hybrid shared secrets of the form Z’ = T || Z. As many systems will use hybrid shared secrets consisting of more than two parts, we suggest that NIST allow hybrid shared secrets of the form Z’ = T_1 || Z || T_2, where T_1 and T_2 auxiliary shared secrets. Z’ = T_1 || Z || T_2 should be secure for all KDFs with acceptable security properties.

Cheers,
John

[Deirdre Connolly]

Agree with Mike here

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB57397B7D390B81010AAEA9339F212%40CH0PR11MB5739.namprd11.prod.outlook.com.

[Sophie Schmieg]

As far as I'm aware, the attack on SHA2 is for the Z || T order, not for the T || Z order (With Z being the secure and T being the insecure part of the IKM). Due to the length extension property of SHA2, knowing SHA2(Z || T) allows you to compute SHA2(Z || pad(T) || X) for arbitrary strings X, without knowledge of Z. There might be a problem with T || Z as well, that I'm not aware of, though. This makes KMAC-SHA2 an insecure MAC as well as an insecure PRF, and by extension an insecure KDF, but if the input is defined to be fixed in length (invalidating the length extension attack), the resulting primitive becomes secure again, and I'm not sure if anyone has demonstrated an exploitable protocol issue even if a so vulnerable KDF is used.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAFR824w00cf_z%2BiaU7pp5XaK951iyAUwY-BD_NwdH_N_OSuW1w%40mail.gmail.com.

--

Sophie Schmieg | Information Security Engineer | ISE Crypto | ssch...@google.com

[Falko Strenzke]

There is no such thing as KMAC-SHA2. KMAC is based on SHA3, see https://csrc.nist.gov/pubs/sp/800/185/final

Falko

Am 16.01.25 um 00:25 schrieb 'Sophie Schmieg' via pqc-forum:

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAaRdwdq27R8JOLE1PyqqUXmXOY5C5BeyHLv99Qzc05pGw%40mail.gmail.com.

--

MTG AG
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.s...@mtg.de
Web: mtg.de

---

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy

[Sophie Schmieg]

Sorry, I used KMAC-SHA2 as a shorthand for "the KMAC construction of H(K || M), used with SHA2 as hash function". Nobody standardized this construction for SHA2, since it is insecure, but you can of course use SHA2 there, it would just not be compliant with any standard and insecure, and you really shouldn't be doing it. The point here was mostly about the fact that, if used with a variable length extra information, this would not be a secure KDF, and that using SHA2 hashes with a H(Z || T) combiner could similarly be seen as insecure, but interestingly enough this is the very order that is considered definitely FIPS compliant.

[John Mattsson]

Hi,

FYI, Ericsson sent the following comment to NIST on the SP 800-56 Subseries
https://emanjon.github.io/NIST-comments/2025%20-%20SP%20800-56%20Subseries.pdf

Some of the comments/suggestions:

 

• The suggestion in SP 800-227 ipd to allow hybrid shared secrets of the form 𝑆_1 ‖ 𝑆_2 ‖ … ‖ 𝑆_t, where at least one of the shared secrets 𝑆_i is NIST approved seems perfect.
  
  
• Define a KDF as a PRF that maintains collision resistance and preimage resistance even when the key is known.

 

• Recommend KMAC whenever possible.
  
  
• Remove all references to paywalled standards

 

• Encourage the use of X25519 and X448, as specified in SP 800-186, in hybrid schemes aligning with de facto Internet standards for TLS, DTLS, QUIC, and SSH.

 

• Keep the requirement “An ephemeral private key shall be used in exactly one key-establishment transaction” and explicitly include it in all NIST specifications on KEMs.

Cheers,
John Preuß Mattsson,