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? 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? Where an IND-CCA2 issue in HQC was found after
it was selected for standardization? 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?
Funny enough there doesn't seem to be anything wrong with the "moon math" as
far as we know, it was just the usual issue that a hard math problem got
weakened in the process of turning it into a cryptosystem, the torsion points
had always been the most likely issue, we just didn't see the right tool to
use them. Are we going to say the same about power-of-2 cyclotomics in a few
years?
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. 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 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.
All the best
Tanja
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]> wrote:
>
> On Tue, Jun 30, 2026 at 2:09 PM Blumenthal, Uri - 0553 - MITLL <
> [email protected]> 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]
> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
