Uri, Your example shows that the system works – a WIP in progress that doesn’t pan out shouldn’t be counted. But, in any case the difference is large enough to be significant (maybe someone with access to OpenAlex can do a better job).
My point about the dates is about relevancy. People have known about factoring integers for millennia, but that doesn’t strengthen our confidence in RSA. People have known about lattices for hundreds of years. Ditto. The question is how much effort has been put into attempts at breaking, or more precisely at solving the underlying puzzle. For MLKEM the critical moment isn’t Oded Regev’s 2005 realization that LWE weaponizes CVP, but rather the 1980s when people started trying to crack CVP/SVP. Y(J)S From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Sent: Thursday, February 26, 2026 2:06 PM To: John Mattsson <[email protected]> Cc: [email protected] Subject: [EXTERNAL] [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe John, My table was supposed to show when a given cryptosystem was standardized initially - aka, regarded by the community and the (international?) standards bodies as “good and mature enough to rely upon it”. Not when it reached the “no more standards involving it” point. (Though I personally find ridiculous investing time into new ECC-based standards now, when the majority is looking for ways to leave RSA and ECC.) Yaakov, I tried to depict the rough dates when the underlying mathematical concept/problem was studied, not when cryptographers started considering it. I take your point about gauging efforts by the number of publications, though unsure how representative it is (plus, studies do not necessarily indicate meaningful - threatening - cryptanalytic progress). As a point of comparison, many years ago, I thought I noticed an exploitable differential weakness in the Russian GOST block cipher - so I started to plan a paper. Further analysis, however, showed that the number of rounds destroyed any potential for exploitation way before it becomes meaningful. That paper never materialized - and Google Scholar doesn’t reflect my effort that proved fruitless. (Later, John Kelsey discovered and published a related-key attack against GOST. ;-) — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory On Feb 26, 2026, at 06:07, John Mattsson <[email protected]<mailto:[email protected]>> wrote: Rob Sayre wrote: >No one trusts NIST I am European, and I have a high trust in NIST. They have done an excellent job in standardizing AES, SHA-3, Ascon, ML-KEM, ML-DSA, and SLH-DSA. These algorithms were not designed by NIST, they were designed ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd Rob Sayre wrote: >No one trusts NIST I am European, and I have a high trust in NIST. They have done an excellent job in standardizing AES, SHA-3, Ascon, ML-KEM, ML-DSA, and SLH-DSA. These algorithms were not designed by NIST, they were designed by cryptographers from around the world, most of them European 🇪🇺. Blumenthal, Uri wrote: >ECC 1985 ~1998–2000 In addition to the standardization of X25519 and X448 in 2016, ECC standardization efforts are still ongoing in 2026. https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ Tanja Lange wrote: >The main change was that there had been a patent deal between Certicom and the NSA that made using ECC possible, that some research managed to route around the patents (which e.g. led to the Brainpool curves) Correct me if I am wrong, but my understanding is that Certicom's patents primarily covered implementation optimizations, and that it was possible to implement P-256 ECDHE and ECDSA without licensing Certicom patents by avoiding those techniques. Brainpool addressed the issue by choosing parameters that made high-performance implementations impossible, even today. That said, the patent landscape was very unclear and had a significant dampening effect on the deployment of ECC. Cheers, John From: Yaakov Stein <[email protected]<mailto:[email protected]>> Date: Thursday, 26 February 2026 at 09:41 To: Blumenthal, Uri - 0553 - MITLL <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) < Lattice crypto 1996 2022–2024 ~25 years Lattices: ~150–200 years Well, the 150-200 years is a bit doubtful. The issue is not “lattices” (crystallography has been around for a long time), the question is the difficulty of the CVP or SVP. While true that Mikowski’s theorem implying existence of small lattice vectors is from 1889 (137 years ago) it doesn’t say anything about the difficulty of finding such a small vector. The van Emde Boas “SVP is NP-hard” conjecture dates from 1981 (45 years ago) and was proven by Ajtai in 1997 (29 years ago). Of course, modern integer factorization methods date from the late 1970s and similar dates apply to the discrete log problem. So, the difference is not substantial if the earliest date is the criterion. But you really can’t compare the effort that has been put into factorization or ECDLP to date to that put into lattice problems. (Google Scholar retrieves about 150K integer factorization results, 100K ECDLP ones and 20K SVP/CVP entries.) Y(J)S From: Blumenthal, Uri - 0553 - MITLL <[email protected]<mailto:[email protected]>> Sent: Wednesday, February 25, 2026 11:39 PM To: DA PIEVE Fabiana <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) > Admittedly your answer (reported here below) was not addressing my concerns. > . . . . . > A hybrid still has a chance of being secure if old good crypto would be > successfully attacked, so your argument does not stand. Let me repeat myself. If the data must remain secure for a long time, then the Classic part does not help, and the security of that data lies solely within the PQ component. Which part of this “does not stand”? The only difference the Classic part makes is probably preventing the data from being compromised early — which for long-time-valuable data is not enough. (This extra protection usually does not hurt, but in several use cases it does not help, and it adds the cost of introducing extra complexity in codebase and infrastructure management. For some — it is OK, so there’s tls-ecdhe-mlkem draft, that nobody objects to. For others — it is not OK, their needs are addressed by tls-mlkem.) > To build confidence in RSA took 20 years or more. I do not expect that PQC > will have such a remarkably different path. You must have missed one of my previous emails — let me (again) repeat myself: System Proposed Standardized Lag-to-Standardization Math-Studied-For-How-Long RSA 1977 ~1993–1995 ~15–20 years Number theory: 2000+ years ECC 1985 ~1998–2000 ~13–15 years Elliptic curves: ~150 years Lattice crypto 1996 2022–2024 ~25 years Lattices: ~150–200 years McEliece 1978 2024 ~46 years Codes: ~60-75 years I hope this table is self-explanatory, and addresses your comment. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
