[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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 <john.mattsson=[e-mail]> 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 <ystein=[e-mail]>
> Date: Thursday, 26 February 2026 at 09:41
> To: Blumenthal, Uri - 0553 - MITLL <[e-mail]>, [e-mail] <[e-mail]>
> 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 <[e-mail]>
> Sent: Wednesday, February 25, 2026 11:39 PM
> To: DA PIEVE Fabiana <Fabiana.DA-PIEVE=[e-mail]>; [e-mail]
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]