On Fri, Feb 20, 2026 at 01:18:52AM +0000, Peter Gutmann wrote:
> Unless it's PQC, in which case the minute it's in the spec, in fact long
> before there's even a spec for it, everyone will be clamouring for it to
> appear. Not arguing against publication, just pointing out that when it comes
> to post-magic crypto the only choices you have are "support it" or "support
> it".
OpenSSL 3.5 and later do indeed provide an implementation, but FWIW, the
non-hybrid ML-KEM groups are not enabled by default, both client and
server have to choose to enable them explicitly in their configurations.
Only X25519MLKEM768 is enabled by default, and in 4.0 we'll shortly add
a default fallback to the SecP256r1MLKEM768 hybrid (but without a
predicted client keyshare, so used only after a server HRR, if the
server for some reason supports the P-256, but not the X25519 hybrid).
Once a VIC-20, an abacus or a dog[1] can no longer beat demonstrated
implementations of Shor's algorithm, perhaps the pure ML-KEM variants
would also make sense to enable by default.
Before I take CRQCs as a credible looming issue, a milestone I'd want to
see crossed would be an honest Shor's algorithm factorisation of a
32-bit RSA modulus[2], but perhaps I should first have asked for a
16-bit RSA moduls instead, as that too appears to be currently well out
of reach.
--
Viktor. 🇺🇦 Слава Україні!
[1] https://eprint.iacr.org/2025/1237.pdf
[2] https://scottaaronson.blog/?p=9564#comment-2025810
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
