I have just stumbled upon Dr. Roberto Avanzi's post on LinkedIn. Dr. Avanzi, who is one of the designers of ML-KEM, writes (in an answer to Dr. Bernstein tweet that was shared by Prof. Bill Buchanan), and I quote: "In my opinion the issue is not implementation errors, they can be avoided with the right discipline. But, as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."
I can offer a screenshot of the reply to support its accuracy (as linkedin does not offer a simple mechanism for linking to a specific post and/or reply that I am aware of). I know that this point has been raised before, but the fact that a co-designer of ML-KEM says so publicly, may carry some weight for some people (rather than just cryptographers wanna-bes and trolls suggesting this exact same claim). On Wed, Jul 8, 2026 at 11:54 PM Ilari Liusvaara <[email protected]> wrote: > On Wed, Jun 24, 2026 at 08:00:07AM -0700, Joseph Salowey via Datatracker > wrote: > > This message initiates a new Working Group Last Call for > > draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key > > establishment for TLS 1.3. > > I support publishing this. > > > I do not think hybrids are a major improvment. However, because hybrid > key exchange in TLS 1.3 is extraordinarily cheap, I think ECDH+PQ > hybrids should be used unless following security profile standard > specifying otherwise, CRQCs having rendered traditional cryptography > moot, or system constraints somehow make hybrids impractical. > > And given how close my position is, it takes very little to tilt > the scale the other way. Furthermore, CRQC appearing would instantly > tilt the scale the other way. So I think wanting to use stand-alone > ML-KEM is completely understandable. > > (My position on hybrid signatures is very different due to much > bigger costs, and is not even close to the tipping point.) > > > ML-KEM security, mathematical level: > ------------------------------------ > Post-quantum cryptography is not a type of cryptography, it is attribute > of cryptography. The candidates to NISTPQC were very diverse, and as > different types of cryptography tend to have different attacks (with > some common ones), one can not use failures of other types (e.g., SIKE) > or the general failure rate (there was plenty of "snake oil") as > evidence against Kyber/ML-KEM. > > For the submissions based on lattices, the issues seemed to be mostly > bad parameter choices and some other details. Which is also to be > expected, and does not reflect badly on Kyber/ML-KEM. > > The MLWE problem underlying Kyber/ML-KEM seems to be the best problem > currently available. Decent message sizes combined with loads of > analysis. LWE would be even better from analysis standpoint, but the > message sizes are pretty painful. > > Cryptography based on lattices is not new. NTRU is from 1996, and LWE > (which is commonly regarded as better than NTRU) is from 2005. In > addition Kyber/ML-KEM also has extensive analysis as part of NISTPQC, > probably exceeding any other candidate KEM. Lattices are also a > generally useful topic, and as such have attracted a lot of mathematical > research for a long time. > > And looking at known attacks, it is clear that anything besides > breaking ML-KEM-512 with extreme effort (not going to be worth it) > requires a fundamentally new attack. > > Comparing to ECC, ECC has also seem a lot of analysis since it was > introduced in 1985, and is also based on generally useful topic that > has attracted a lot of mathematical research over a long time. > Breaking the cases that have not already been broken also requires > either quantum computer or a fundamentally new attack. > > > ML-KEM security, implementation level: > -------------------------------------- > Unlike mathematical level, which needs to stand the test of time, the > implementations do not. A well-done implementation is good right off > the gate. A badly-done implementation will remain bad even after > plenty of time. > > Implementation quality is not gated by algorithm understanding or CS > theory. As consequence, implementations do not really improve over > time. More implementations get written, some of those are good. And the > bad implementations tend to patch the worst stuff (but likely never > become good). > > Fortunately, implementation quality of ML-KEM in TLS is not very > important: ML-KEM is not prone to to implementation flaws so bad that > all security is destroyed, hybrid or not. The remaining flaws tend to > be either strongly mitigated by not reusing keys (required by > RFC8446bis) or destroy interop. Hybrids are practically useless here. > > Comparing to ECC, ECC also has history of all kinds of bad > implementations. And some forms of ECC (thankfully not supported in > TLS 1.3) are not resistant to flaws that instantly destroy all > security. > > > > > -Ilari > > _______________________________________________ > 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]
