Bernstein's Blog

Posted Dec 9, 2025 23:42 UTC (Tue) by muase (subscriber, #178466)
In reply to: Bernstein's Blog by chris_se
Parent article: Disagreements over post-quantum encryption for TLS

> ECC isn't new, it's just a couple of years younger than RSA

I know; that was not so well worded on my side. My argument was: If we had applied the "you cannot trust these young algorithms"-logic consistently, therefore we make hybrid _mandatory_ without alternative, we would have ended up with all kinds of combined schemes that'd still pop up as zombies everywhere.

> Your examples don't really make that much sense for this discussion in my eyes [...]

I see your point, but ECC was also about improving security. For a long time, the main benefit of ECC was that you could easily upgrade to a security level that was impractical to achieve with RSA or DH (the speed race came later); and a hybrid scheme RSA1024+P256 would have been a significant security improvement compared to just RSA1024, and would still have provided the fallback in case ECC would have broken.

But the entire area was very different back then, so maybe you're right and it's not a good example^^

> This has obviously changed since then, but the age alone is not a pure indicator. Most cryptanalysis on PQC algorithms has happened in the last 10 years.

Yes and no. Yes, time is not a pure indicator, but that works in both directions. Cryptanalysis has gotten so much better (in methods and quality) that this is not really comparable. Within the last few years we learned more about the PQC algorithms than what we learned about older algorithms in decades, simply because the field has evolved pretty crazy (and because of internet, and knowledge accumulation, and much better tooling and formal models and proofs, etc.). It's safe to say that we know much more about ML-KEM now than we did about AES or ECC when both became adopted.

I mainly included the argument because everyone is always talking about "young" and super new algorithms and stuff; and I wanted to oppose that a bit. The algorithms and math are not as young as many people think, and also not as green re cryptanalysis as many people seem to believe.

> PQC algorithms are fundamentally different: ideally we want to switch to an scheme that _has_ to include a PQC algorithm as soon as possible, for forward secrecy. Classical-only schemes should disappear as fast as possible. And in that scenario having a hybrid scheme is much more sensible.

Here we are in full agreement I think; like I said, IMO a combined scheme is a very reasonable default. I'm totally not opposing a combined scheme, I just don't think it makes sense to oppose an additional and _optional_ PQ-only ciphersuite either.

It's simply not an either-or; and – here we might be in disagreement? – I think ML-KEM is definitely mature enough to deserve its own dedicated cipher suite. Let's call it "experimental" or "special interest" – but I think we should define it, before others come along with proprietary schemes and extensions or custom incompatible suites etc. Nobody needs that^^

to post comments

Bernstein's Blog

Posted Dec 10, 2025 9:47 UTC (Wed) by chris_se (subscriber, #99706) [Link] (3 responses)

> > ECC isn't new, it's just a couple of years younger than RSA
>
> I know; that was not so well worded on my side. My argument was: If we had applied the "you cannot trust these young algorithms"-logic consistently, therefore we make hybrid _mandatory_ without alternative, we would have ended up with all kinds of combined schemes that'd still pop up as zombies everywhere.

I think things were a lot different back then. The main difference is that we've learned that the "the more the merrier" approach to standardizing cipher suites is actually detrimental to security.

But I also disagree with you here, I personally wouldn't have thought it a bad idea if the first introduction of ECC in standards in ~2005 had been a hybrid scheme. In ~2015, different story.

> I see your point, but ECC was also about improving security. For a long time, the main benefit of ECC was that you could easily upgrade to a security level that was impractical to achieve with RSA or DH (the speed race came later);

"impractical" == too slow you mean? Still counts as performance in my eyes.

> It's safe to say that we know much more about ML-KEM now than we did about AES or ECC when both became adopted.

That still doesn't touch my argument that all PQC schemes I've looked at so far are more complicated in their construction than RSA and even ECC.

> It's simply not an either-or; and – here we might be in disagreement? – I think ML-KEM is definitely mature enough to deserve its own dedicated cipher suite. Let's call it "experimental" or "special interest" – but I think we should define it, before others come along with proprietary schemes and extensions or custom incompatible suites etc. Nobody needs that^^

As I've said in another part of this thread: I'm not 100% opposed to standardizing ML-KEM alone to avoid proprietary messes, if it's clearly marked as "do not use unless you really really know what you are doing". But I don't think it's been analyzed enough (due to its complexity) that I'd be comfortable in making this just an optional thing with even just a warning - I'd want this to be actively discouraged and the standard should indicate that it must be disabled by default unless configured otherwise. Give it another 10 years, and more experience in the field with it (especially when it also comes to side channels), and assuming nobody's broken it by then, I'd be happy to go ML-KEM only.

Bernstein's Blog

Posted Dec 11, 2025 0:36 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

I'd want this to be actively discouraged and the standard should indicate that it must be disabled by default unless configured otherwise.

It also needs some kind of protection against downgrade attacks. If you're going to officially discourage its use, there had better not be a way for an attacker to force people to use it in place of more trustworthy algorithms.

Bernstein's Blog

Posted Dec 11, 2025 12:20 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

> But I don't think it's been analyzed enough (due to its complexity)

I think the perceived complexity is related to unfamiliarity. ECC relies on fancy properties of groups, which we know are not PQ safe but are well known in the crypto-community. ML-KEM relies on some linear algebra and probability theory which to me sounds a lot less magic than ECC. Linear algebra and probability theory are some of the most studied areas of mathematics due to their ubiquitous use everywhere.

> that I'd be comfortable in making this just an optional thing

But whose comfort should we be listening to?

FWIW, I think standardizing a pure-PQ algorithm is a good idea because then we can move onto the next phase, namely algorithm implementations. Even though we've been using ECC for ages, making side-channel free implementation is still hard and we need to get the ball rolling on that now, not wait another ten years. It'll probably be at least ten years before any implementation is sufficiently available that people can even think about using it for public sites.

Bernstein's Blog

Posted Dec 11, 2025 12:46 UTC (Thu) by brunowolff (guest, #71160) [Link]

Lattices can use some more study. SIKE went from people thinking it was fine to completely broken not too long ago. There isn't a reason to take that risk now.

Implementors don't need a PQ only version of ML-KEM in the TLS standard to start implementing ML-KEM. There are already implementations. Also timing atacks are taken a lot more seriously now as compared to when AES came about. People are already doing constant time implementations and checking them. In fact there was a screw up in kyberslash where there was a divide using secret data, that was found and corrected not too long ago. There are libraries to help people get this correct on different hardware and compilers.