On Fri, Oct 10, 2025 at 04:01:56PM -0000, D. J. Bernstein wrote:
> Andrei Popov writes:
> > There are regulatory requirements that require NIST curves, whether
> > one likes them or not.
>
> Can you please point to the "regulatory requirements" you have in mind,
> and explain why you believe that the requirements prohibit X25519MLKEM*?
IIRC, rumour has it that those who need a FIPS-validated stack, and have
only an older stack with P-256/P-384 validated, but ML-KEM not yet
validated, can get a validated combination via ML-KEM plus ECDSA, but
not ML-KEM with X25519 or X448.
I don't know which software stacks find themselves in this situation,
but what we do see is that these certainly are not showing in deployment
surveys in non-negligible numbers. So the issue could be more
theoretical than practical.
FWIW, the only hybrid KEM enabled in OpenSSL 3.5+ TLS client and server
by default is "X25519MLKEM768".
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
