Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

211–220 of 260 posts

Re: A cryptography engineer's perspective on quantum computing timelines

#211
post #39

What surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it. The weird thin…

[dead]

Re: A cryptography engineer's perspective on quantum computing timelines

#212
post #24

Earlier quoted context omitted.

So... In 2013 I was working for Mozilla adding TLS 1.1 and 1.2 support into Firefox. It turns out that some of the extensions common in 1.1, in some instances caused PDUs to grow beyond 16k (or maybe it was 32k, can't remember.). This caused middle boxes to barf. Sure, they shouldn't barf, but they did. We discovered the problem (or rather one of our users discovered the problem) by increasing the key size on server…

A few points here: There is already very wide use of PQ algorithms in the Web context [0], which is the most problematic one because clients need to be able to connect to any site and there's no real coordination between sites and clients. So we're exercising the middleboxes already. The incident you're thinking of doesn't sound familiar. None of the extensions in 1.1 really were that big, though of course certs can…

[0] was an excellent read, thank you for sharing!

Re: A cryptography engineer's perspective on quantum computing timelines

#213
post #174

Earlier quoted context omitted.

The Manhattan project had a huge impact but it was not that big as far as efforts in the war went (they managed to hide the budget allocated to the project from most of congress, for example).

Yeah and some of the figures often quoted like consuming 14% of the electricity produced in the US are wrong, it was below 1%. https://ui.adsabs.harvard.edu/abs/2011APS..APRH13004R/abstra...

It was like 0.5% GDP. It wasn’t insane, but still, you are right.

It was very focused. What do we get out of the F-35 program? By comparison, it has eaten (projected total lifetime cost) 2 trillion dollars. It is 4.5% of the GDP. I had no idea. This is just a military and government contractor subsidy. What are we doing…

Re: A cryptography engineer's perspective on quantum computing timelines

#214
post #50

Earlier quoted context omitted.

The thing is, producing the right isotopes of uranium is mostly a linear process. It goes faster as you scale up of course, but each day a reactor produces a given amount. If you double the number of reactors you produce twice as much, etc. There is no such equivalent for qubits or error correction. You can't say, we produce this much extra error correction per day so we will hit the target then and then. There is al…

So today you have 1 gram. No bomb. Tomorrow you have 2 grams. Still no bomb. ... 365 days later, you have 365 grams after spending ungodly amounts of energy to separate isotopes. AND STILL NO BOMB! Not even a small one. These scientists are just some bullshit artists. 52kg later: BOOM!

But you know beforehand how much you need. We can measure and make predictions with accuracy.

Re: A cryptography engineer's perspective on quantum computing timelines

#215

Earlier quoted context omitted.

Super important: Don't replace traditional (elliptic curve) Diffie-Hellman with ML-KEM, but enhance it by using hybrid key exchanges . Done thusly, you need to break both the classical and post-quantum cryptography to launch an attack. If you worry about a >=1% risk of quantum attacks being available soon, you should also worry about a >=1% risk of the relatively new ML-KEM being broken soon. The risk profile is pret…

How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean…

> when ECDH is nearly guaranteed to be broken in five years

Says who?

There's a big difference between “we can't be sure that ECDH stays secure for five more years” and “ECDH is nearly guaranteed to be broken”. There has been two major papers in the beginning of the year that advanced the state of the art enough to question the prior assumption about the slowness of QC progress. Now we know that rapid advances are possible and we must take that into account in risk assessment. But that doesn't mean that rapid advances are guaranteed. Things could stay stagnant for 15 more years at this point before the next breakthrough. And if that's the case, then ECDH could very well remain relevant for the remaining century.

We just cannot know if it happens, so we can't take the risk. But that doesn't mean that we are certain that the risk will materialize.

Re: A cryptography engineer's perspective on quantum computing timelines

#216
post #39

What surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it. The weird thin…

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-toleran…

> Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part.

I don't like this analogy very much, because in practice making a nuclear reaction is much, much easier than making a nuclear bomb. You don't need any kind of enrichment or anything, just a big enough pile of natural uranium and graphite [1].

Making a bomb on the other hand, required an insane amount of engineering: from doing isotope separation to enrich U235 to an absurd level (and / or, extract plutonium from the wastes of a nuclear reactor) to designing a way to concentrate a beyond critical mass of fissile element.

The Manhattan project isn't famous without reason, it was an unprecedented concerted effort that wouldn't have happened remotely as quickly in peacetime.

[1]: https://en.wikipedia.org/wiki/Chicago_Pile-1

Re: A cryptography engineer's perspective on quantum computing timelines

#217

Earlier quoted context omitted.

Super important: Don't replace traditional (elliptic curve) Diffie-Hellman with ML-KEM, but enhance it by using hybrid key exchanges . Done thusly, you need to break both the classical and post-quantum cryptography to launch an attack. If you worry about a >=1% risk of quantum attacks being available soon, you should also worry about a >=1% risk of the relatively new ML-KEM being broken soon. The risk profile is pret…

How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean…

> How do you mean the risk profile is comparable

Exactly in the way the succeeding sentence defines: "For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated."

> when ECDH is nearly guaranteed to be broken in five years

Most of your argument (and that of many others pushing the contra-hybrid point) hinges on this. I don't think this position is justified. I believe there is significant risk for quantum attacks in the near term (and thus fully support the speedy adoption of hybrids), yes, but quite far away from certainty. Personally, I'd even say better than coin-flip is pushing it. I mean, look at what Scott Aaronson is writing on that matter:

"I also continue to profess ignorance of exactly how many years it will take to realize those principles in the lab, and of which hardware approach will get there first. […] This year [=2025] updated me in favor of taking more seriously the aggressive pronouncements—the “roadmaps”—of Google, Quantinuum, QuEra, PsiQuantum, and other companies about where they could be in 2028 or 2029." -- https://scottaaronson.blog/?p=9425

This is nothing like "nearly guaranteed" in five years.

> and Kyber is two decades old

But the implementations aren't and it's not been under heavy scrutiny for that long. One can very much make the point that we weren't that critical when elliptic curve cryptography entered the scene, but we do now have the luxury to have these heavily battle-tested primitives and implementations at our disposal, so why throw them out of the window so eagerly? Also an interesting comparison to elliptic curve cryptography is that it took until 2005 to get good key exchanges primitives and until 2011 to get good signature primitives (Curve25519, now known as X25519, and Ed25519 respectively) and mainstream availability of those took waaaay longer.

Coming back to this again, for second remark:

> when ECDH is nearly guaranteed to be broken in five years

Another important point is all quantum attack on ECDH will require inherently expensive equipment for the foreseeable future, see adgjlsfhk1's comment https://news.ycombinator.com/item?id=47665561 , whereas a stupid Kyber implementation error in a mainstream library can very likely end up being attackable by a Metasploit plugin. Our threat model should most definitely include nation state attackers prominently, but these are not at all the only attackers that we should focus on. There is still significant value in keeping out attackers that did not spend >100k$ on equipment.

> Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean you have to repeat it uncritically.

I did not repeat it uncritically, I just happen to share his conclusion, even after months of following the pro and contra discussion. Also, how can you say he complains without reason? He has explained them at length, see https://cr.yp.to/2025/20250812-non-hybrid.pdf for example. Whether his methods of complaining are commendable or effective is another topic, though.

Re: A cryptography engineer's perspective on quantum computing timelines

#218

Earlier quoted context omitted.

I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. However that does not mean that the switch should really be done as soon as it is possible, because it would add unnecessary overhead. This could be done by distributing a set of post-quantum certificates, while continuing to allow the use of the existing cert…

How do you do revocation or software updates securely if your current signature algorithm is compromised?

The actual revocation needn't be secure. False revocations are an oxymoron.

The practice around revocations need to be secure of course, but that's more on an engineering problem than a cryptographical.

Re: A cryptography engineer's perspective on quantum computing timelines

#219
post #50

Earlier quoted context omitted.

The thing is, producing the right isotopes of uranium is mostly a linear process. It goes faster as you scale up of course, but each day a reactor produces a given amount. If you double the number of reactors you produce twice as much, etc. There is no such equivalent for qubits or error correction. You can't say, we produce this much extra error correction per day so we will hit the target then and then. There is al…

So today you have 1 gram. No bomb. Tomorrow you have 2 grams. Still no bomb. ... 365 days later, you have 365 grams after spending ungodly amounts of energy to separate isotopes. AND STILL NO BOMB! Not even a small one. These scientists are just some bullshit artists. 52kg later: BOOM!

Not a very good analogy, because by the time you get 26 kg, I still have 71 years before you get the bomb.

Re: A cryptography engineer's perspective on quantum computing timelines

#220

Earlier quoted context omitted.

How do you do revocation or software updates securely if your current signature algorithm is compromised?

The actual revocation needn't be secure. False revocations are an oxymoron. The practice around revocations need to be secure of course, but that's more on an engineering problem than a cryptographical.

Can you explain a bit more what you mean by "secure" in the context of "actual revocations"? The oxymoronic nature isn't self-evident enough for me to catch your intended meaning before my first cup of coffee.
Post reply on HN