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]> 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]> > 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]> >> <[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. >> >> 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/ to learn about how we use this >> information. >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
