On Sat, May 23, 2026 at 03:58:02PM -0000, D. J. Bernstein wrote: > First, risk comparison has to look at not just probability but impact. > For example: https://arxiv.org/abs/2603.28846 shows that a plausible > model of a not-many-years-from-now quantum computer will be able to > break about 2^15 ECC keys per year. That's very bad for those keys, > times the number of quantum computers that the attacker can afford at > that point, but it's still far smaller than the number of PQ keys that > one would expect to be broken via a single PQ software bug.
Perhaps I've been skimming all the wrong posts, but finally I'm looking at a tangible argument rather than litigation of process or motivations, in which you do in fact assign more weight to the risk of near-term PQ-compromise and less to the import of near-term ECC obsolescence than my strawman hypothetical "NSA" posture. That sort of argument would I think have carried more weight if clearly articulated and adhered to from the outset. This is why, for example, the default supported groups configuration in OpenSSL prioritises the X25519MLKEM768 KEM over all other key agreement protocols and does not presently include pure mlkem (implemented, but not enabled by default). Where we part ways is on whether it makes sense to vehemently oppose publication of the PQ-only algorithms. Your case for hybrids will convince those who are prepared to be convinced, and if positioned less stridently perhaps even some who are on the fence. But I don't see the strategy so far as likely to win broad support. The below is reasonable material to include in an argument that hybrids are prudent, and to publish a document advocating their use. FWIW, my advice is to build that case, rather than to fight a conspiracy. Perhaps it is too late switch tactics, or my instinct is way off, your choice of course, good luck. > Second, the relevant security comparison is not between PQ and ECC, but > between PQ and ECC+PQ, two similar-cost options that both provide the > same basic feature of _trying_ to protect against quantum computers. > The basic advantage of ECC+PQ is that, even when the PQ key is broken, > the ECC key will often save the day. Let's say > > * the PQ key is broken with probability q, and > * for broken PQ keys the ECC key is broken with conditional > probability p, saving the day with conditional probability 1-p; > > then ECC+PQ keys are broken with overall probability only pq, which is > much smaller than q for most possible (p,q) pairs. > > Hypothesizing that p is larger than q, or even much larger than q, is > missing the point. For example, imagining that p = 1/100 and q = 1/10000 > means that 1 out of every 10000 PQ keys is broken while only 1 out of > every 1000000 ECC+PQ keys is broken, making ECC+PQ a vastly better > option (100x less damage at similar cost). Saying that ECC is more > likely to fail than PQ in this scenario is irrelevant to the conclusion > that ECC+PQ is by far the best choice. > > To imagine that q is only negligibly different from pq, one would have > to make the wild claim that q is negligible or the wild claim that 1-p > is negligible; basically, that every PQ key is safe, or that every ECC > key is broken. Those scenarios aren't inconceivable, but competent risk > management also considers other scenarios. > > > If CrQCs take much longer to appear than recent (circa 2029) speculative > > timeframes suggest, and in that extended timeframe ML-DSA falls to novel > > cryptanalysis, you'd be proved right. > > Huh? My 2023 quantum-risk-assessment talk for the Federal Reserve > TechLab gave a median estimate of 2029 for secret quantum attacks > breaking RSA-2048 and a median estimate of 2032 for public demos: > > > https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf#page.10 > > I pointed out two "common mistakes analyzing this risk", one being > "assuming attackers aren't ahead of us", the other being "watching > advances in #qubits and in qubit error rates but not in algorithms". > > I was already on record long before 2023 estimating the same 2032 for > public quantum attacks. The mechanisms I use to predict development > speed haven't needed any radical adjustments. The only reason that > > https://cr.yp.to/talks/2017.09.20/slides-djb-20170920-quantum-4x3.pdf > > says 2033 rather than 2032 is that Latincrypt is every second year. > > Here in 2026, the latest improvements in algorithms seem to have > triggered a stampede of people screaming things like "PANIC! Nobody > expected this" and "Quantum FUD has been around for decades BUT NOW IT'S > REAL AND THE APOCALYPSE IS SCHEDULED FOR 2029" and "Protect yourself > RIGHT NOW by injecting bleach". > > I don't find it surprising that a failure to pay attention leads to a > bipolar switch from unjustified exaggerations in one direction ("quantum > computers aren't a real threat") to unjustified exaggerations in the > opposite direction ("ECC is useless"). But I would think that someone > saying "We told you for many years to trust cryptosystem X, but, oops, > it's actually giving away all your data; please panic right now" would > realize how crazy it sounds to follow up by saying "We're telling you to > trust cryptosystem Y". What happens if Y fails too? > > We have ECC sitting around already. Double signatures with ECC+PQ are, > internally, continuing to sign with ECC _and_ signing with PQ, so that > many different types of potential PQ failures still face the attacker > with the problem of breaking an ECC key. This has the same easy external > interface as removing the ECC part (contrary to various claims that > suddenly appeared on the TLS mailing list during WGLC and that still > haven't been retracted---Mike Ounsworth commented that there's a "crazy > amount of mis-understanding of composites on display here"), and it has > negligible extra cost. This core argument for ECC+PQ is _not_ dependent > upon any guesses for when the first quantum computers will appear. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
