> 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.”
Well, if Dr. Avanzi isn’t confident enough in his design, what can I say, except that perhaps he should’ve worked harder back then? However, repeating the argument that people appear to keep forgetting or ignoring: * For data that does not need to remain secure beyond CRQC, adding ECC is great. There are costs, but who cares. * For data that does require confidentiality beyond CRQC, adding ECC won’t help, because everything will depend on the PQ part, ML-KEM in this case. * People tend to know which of the two categories above their data belongs to. I suspect that those of the latter category do not want to encumber their implementations with ECC. While those of the prior — do... So, for data with “prolonged” sensitivity, if Dr. Avanzi didn’t design ML-KEM well enough — that data is dead, regardless of whether ECC is bolted on or not. I don’t bother with the case when the exposure-caused damage drops down gradually (disclosing now is extremely bad, next year — quite bad, in five years — I’d rather not disclose it but if it leaks it’s no big deal). On Wed, Jul 8, 2026 at 11:54 PM Ilari Liusvaara <[email protected] <3f784430-3143-4097-8b4a-0730c5c67898>> 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] <8454960a-8e7c-4704-855d-d3a28353fde0> To unsubscribe send an email to [email protected] <9ce685c3-97e6-42b6-bf52-fee2592f83f4>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
