Just to clarify Kris, you are _asking_ if there is a plan? I don't know
if Quynh can comment but
Yes, I was wondering if there is a concrete plan to relax the ordering
requirement. After yesterday's meeting, I understood
that this is something NIST may consider.
[1] See Mike's notes
https://mailarchive.ietf.org/arch/msg/spasm/0HYpMgRiqUF61Z90BYuS-RfBWDU/
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 <k...@amongbytes.com> 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 <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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
