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 <jpix...@gmail.com> 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 <k...@amongbytes.com> 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 <cjt=40post-quantum....@dmarc.ietf.org> <mailto:cjt=40post-quantum....@dmarc.ietf.org> 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 visitwww.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 atwww.post-quantum.com/privacy-policy/ <http://www.post-quantum.com/privacy-policy/> to learn about how we use this information. _______________________________________________ TLS mailing list --tls@ietf.org To unsubscribe send an email totls-le...@ietf.org_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
