Hi Eric and all, NIST allows the shared secret key, called K, of a ML-KEM to be in the place of Z (a raw shared secret) in 56C.
In 56C, Z can be X||Y, but X must be either a raw shared secret generated by a NIST-approved key agreement/establishment method or K. A X25519’s raw shared secret or a pseudorandom key generated from it is not a NIST-approved X. A NIST-approved ECDH method produces shared secret key(s), not a raw DH shared secret because it always has a KDF which outputs the desired key(s) (the desired keying material) the application on top of it needs. Regards, Quynh. From: Eric Rescorla <[email protected]> Sent: Thursday, October 17, 2024 8:54 AM To: Joseph Birr-Pixton <[email protected]> Cc: CJ Tjhai <[email protected]>; [email protected]; TLS List <[email protected]> Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02 Can we get a ruling on this from NIST? Quynh? -Ekr On Thu, Oct 17, 2024 at 2:32 AM Joseph Birr-Pixton <[email protected]<mailto:[email protected]>> wrote: Please could we... not? It certainly is one interpretation of that section in SP800-56C. Another is that TLS1.3 falls outside SP800-56C, because while HKDF kinda looks like section 5, none of the allowed options for key expansion specified in SP800-108 (and revs) are the same as HKDF-Expand. "KDF in Feedback Mode" gets close, but (ironically) the order and width of inputs are different. Given people have shipped FIPS-approved TLS1.3 many times by now (with approved HKDF implementations under SP800-56C!), we can conclude that FIPS approval is simply not sensitive to these sorts of details. I also note that tls-hybrid-design says: > The order of shares in the concatenation > MUST be the same as the order of algorithms indicated in the > definition of the NamedGroup. So we're not even being consistent with something past WGLC? Thanks, Joe On Thu, 17 Oct 2024 at 08:58, Kris Kwiatkowski <[email protected]<mailto:[email protected]>> wrote: Yes, we switched the order. We want MLKEM before X25519, as that presumably can be FIPS-certified. According to https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf, section 2, the shared secret from the FIPS-approved algorithm must precede the one that is not approved. X25519 is not FIPS-approved hence MLKEM goes first. P-256 is FIPS-approved. The ordering was mentioned a few times, and there was some discussion on github [1] about it. But, maybe the conclusion should be just to change the name X25519MLKEM768 -> MLKEM768X25519 (any opinion?) That would be just a name change, so the code point value should stay the same. Cheers, Kris [1] https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942 On 17/10/2024 08:24, Watson Ladd wrote: Did we really switch the order gratuitously on the wire between them? On Thu, Oct 17, 2024 at 12:02 AM CJ Tjhai <[email protected]><mailto:[email protected]> wrote: Hello, The X25519MLKEM768 scheme defined in the document is a concatenation of MLKEM768 and X25519, why is it not named MLKEM768X25519 instead? For SecP256r1MLKEM768, the naming makes sense since it's a concatenation of P256 and MLKEM768. Apologies if this has already been asked before. Cheers, CJ ________________________________ PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received this email in error, any review, use, dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the error by return email and please delete this message from your system. Thank you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<http://www.post-quantum.com/>. In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy notice at www.post-quantum.com/privacy-policy/<http://www.post-quantum.com/privacy-policy/> to learn about how we use this information. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
