> If you are aware of a weakness in ML-KEM, please enlighten us.
I second this request — please share. On Tue, Jun 30, 2026 at 6:29 PM Tanja Lange <[email protected] <12a50fc4-0698-4a29-b175-e9e986837384>> wrote: > You mean the competition where Rainbow got broken in February 2022, a few > months after the end-of-2021 date which NIST had announced as the planned end > of the competition? Yes. Of 82 submissions, 69 were accepted into the first round. Many of those were broken or otherwise eliminated during the 8-year process — on top of prior analysis. You might remember that, e.g., NTRU was published in 1996 (peer-reviewed in 1998). To me, that strongly suggests that the NIST process worked reasonably well. > Where GeMSS had its underlying hardness assumption pulled > out under it in November 2020? Where we're having an entire extra competition > on signatures because of this? Allow me to correct: the additional signature process is primarily because NIST wanted to diversify the PQ signature portfolio, especially beyond structured lattices, and also because some applications need shorter signatures and/or faster verification than the initial standards provide. > Where an IND-CCA2 issue in HQC was found after it was selected for > standardization? HQC is still moving through standardization: NIST selected it in March 2025 as a second PQC KEM, and the later HQC update appears to address the raised transform/rejection issue. So I would describe this as a real but apparently fixable specification issue, not as a break of the underlying HQC hardness assumption. > Not to mention all the other systems that went down along the away, despite > being > seemingly based on solid assumptions. Did you count how many of them used > lattices? NIST’s Round 1 material classified roughly 25 accepted candidates as lattice-based. Over the 8-year process, weaker proposals across all families — including many lattice-based ones — were attacked, revised, or eliminated. So the mere fact that some lattice-based candidates failed is not evidence that ML-KEM is flawed. If you are claiming that because many lattice-based candidates were flawed, ML-KEM is also flawed, please provide evidence and references. > In the short term I'm more concerned about implementation errors, given the > scale of > the new rollout, and consider it reckless to give up on existing protections > that have > gone through years of vetting and fixes. I agree that implementation errors are a real concern, especially at rollout scale. But this concern is not specific to ML-KEM: hardware platforms change, implementations get rewritten, and bugs are also found in old, heavily tested code. So I do not think implementation risk alone justifies treating ML-KEM as uniquely suspect. >In the long run I'm not convinced that what we'll switch to after ECC + ML-KEM >is ML-KEM, > it’s much more likely that by then we'll have a different system -- in the > optimistic case > because we can do so much better (already now we have systems that are smaller > and/or faster and based on the same ideas as Kyber, 9 years more of research > make a difference), > and in the pessimistic case because we need to increase the parameters or > even move to a different system. I’m cautious about forecasting here, but out of curiosity, what “smaller and/or faster” systems do you have in mind? References, please? Especially if they appear in peer-reviewed papers? > I don’t like the term "agility" and have complained about the > misunderstandings it creates, > but any change in systems now should be done in a way to make the next one > easy. I agree that migration mechanisms matter, but that is a separate discussion from whether there is a concrete weakness in ML-KEM. On Tue, Jun 30, 2026 at 05:20:44PM -0400, Soatok Dreamseeker wrote: > Something that has already happened to a moon math submission that was not as > widely understood as lattices. SIKE being broken was the international > standardization effort successfully working to motivate folks to find attacks > against novel cryptosystems. Using it as an indictment of an unrelated > algorithm is alarmingly ignorant. > > On Tue, Jun 30, 2026 at 5:13 PM Rob Sayre <[email protected] > <809014dd-d22f-4481-9a4d-74d60bf51013>> wrote: > > On Tue, Jun 30, 2026 at 2:09 PM Blumenthal, Uri - 0553 - MITLL < > [email protected] <c8c2ff62-0db5-475b-b35c-f9ed9621b925>> wrote: > > People seem to keep forgetting (or ignoring) the whole purpose of the > PQ. > > If your data won’t remain sensitive by the time CRQC arrives - you > don’t en need a hybrid. Just use your Classic ECC, experiment with PQ > or not, and prepare for eventual transition at some point in the > future. > > If your data will remain sensitive - then the difference between “it > got compromised today” and “it got compromised with CRQC” is small, and > ECC won’t help at all. > > > > That's not the argument, though. It's that classical attacks might break > the PQ algorithms. Something that has already happened. > > thanks, > Rob > > _______________________________________________ > TLS mailing list -- [email protected] <b5e732ac-b551-4c60-9e92-cc4755522d32> > To unsubscribe send an email to [email protected] > <c5ad78cd-bbd6-4f00-aa15-82b6bc4f1003> > > _______________________________________________ > TLS mailing list -- [email protected] <320254fb-1b8f-40b2-8006-642d01173a3b> > To unsubscribe send an email to [email protected] > <ec2a40f5-b7ab-4821-b691-8e19c94ddcf1>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
