Hi all, I support the publication of this draft.
Cheers, Thom > Op 20 feb 2026, om 04:56 heeft Viktor Dukhovni <[email protected]> het > volgende geschreven: > > 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
