On Friday, 10 October 2025 19:42:49 CEST, Viktor Dukhovni wrote:
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.
Unless something unexpected happens, RHEL 10.1 OpenSSL will have
this behaviour: in FIPS mode X25519MLKEM768 will not be offered or
accepted.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
