>>> This is equivalent to asking, in 1979, whether anyone is aware of weaknesses >>> in RSA. >> >> RSA was published in 1977, and predating it DH — in 1976. > > Precisely. ML-KEM has been in use, mostly due to being baked into the > Chromium monoculture, for around two years now. > > 1979 - 1977 is also around two years last time I checked. > Unlike your values, I didn't just pull the value 1979 out of thin air.
The arithmetic is not the problem; the choice of starting point is. You are counting time since broad browser deployment and treating it as time available for public cryptanalysis. Those are not the same quantity. Kyber did not become available for analysis when Chromium enabled X25519Kyber768/ML-KEM in TLS. Kyber was public in the NIST PQC process in November 2017, selected for standardization in 2022, and standardized as ML-KEM in FIPS 203 in 2024. If one wants an RSA analogy, the relevant clock is the public cryptanalytic clock, not the Chrome release train. So yes, "1979 - 1977 = 2" is correct. The sleight of hand is pretending that the corresponding ML-KEM clock starts at Chromium deployment rather than at Kyber's public submission and subsequent NIST review. It is also worth being precise about the proof claim. Nobody is claiming a proof that Module-LWE is hard. The point is that ML-KEM has machine-checked proof work connecting the specified construction to explicit assumptions, and implementation-correctness work connecting implementations to the specification. That is a materially stronger evidentiary position than "has anyone heard a rumor of a weakness?" If your claim is only that ML-KEM has had about two years of high-volume browser deployment exposure, fine. If your claim is that ML-KEM has had only about two years of public cryptanalytic exposure, that is simply false.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
