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]> wrote: > > This Message Is From an External Sender > This message came from outside the Laboratory. > 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]> > Date: Thursday, 26 February 2026 at 09:41 > To: Blumenthal, Uri - 0553 - MITLL <[email protected]>, [email protected] > <[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]> > Sent: Wednesday, February 25, 2026 11:39 PM > To: DA PIEVE Fabiana <[email protected]>; > [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] > To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
