Just to clarify Kris, you are _asking_ if there is a plan? I don't know if Quynh can comment but
NIST have said publicly that they plan to clarify hybrid KEMs in the forthcoming SP 800-227: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/6_D0mMSYJZY/m/3DwwIAJXAwAJ > is there a plan to change SP800-56Cr2, so that it allows to > use combination of two shared secrets where one was generated by FIPS-approved > technique, BUT concatenated in any order. On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski <[email protected]> wrote: > Indeed, that would be good inside. > > Additionally, is there a plan to change SP800-56Cr2, so that it allows to > use combination of two shared secrets where one was generated by > FIPS-approved > technique, BUT concatenated in any order. > > I understand it is potentially more complicated for ACVP testing, but it > seems it would solve a problem. Does order matter from the security > perspective? > On 17/10/2024 13:53, Eric Rescorla wrote: > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
