Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

41–50 of 260 posts

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

#41
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-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

To summarize, the hard part of scalable quantum computation is error correction. Without it, you can't factorize essentially anything. Once you get any practical error correction, the distance between 32-bit RSA and 2048-bit RSA is small. 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.

This is what the experts know, and why they tell us of the timelines they do. We'd do better not to dismiss them by being smug about our layperson's understanding of their progress curve.

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

#42
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…

IIRC the largest number factored still remains 21

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

#43
post #30

Earlier quoted context omitted.

As a practical matter, revocation on the Web is handled mostly by centrally distributed revocation lists (CRLsets, CRLite, etc. [0]), so all you really need is: (1) A PQ-secure way of getting the CRLs to the browser vendors. (2) a PQ-secure update channel. Neither of these require broad scale deployment. However, the more serious problem is that if you have a setting where most servers do not have PQ certificates, th…

Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time…

> In both cases, you need to start moving now and gain little from trying to time the switchover.

There are a number of "you"s here, including:

- The SDOs specifying the algorithms (IETF mostly)

- CABF adding the algorithms to the Baseline Requirements so they can be used in the WebPKI

- The HSM vendors adding support for the algorithms

- CAs adding PQ roots

- Browsers accepting them

- Sites deploying them

This is a very long supply line and the earlier players do indeed need to make progress. I'm less sure how helpful it is for individual sites to add PQ certificates right now. As long as clients will still accept non-PQ algorithms for those sites, there isn't much security benefit so most of what you are doing is getting some experience for when you really need it. There are obvious performance reasons not to actually have most of your handshakes use PQ certificates until you really have to.

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

#44
post #5

This is a good take, there's really not much to argue about. >[...] the availability of HPKE hybrid recipients, which blocked on the CFRG, which took almost two years to select a stable label string for X-Wing (January 2024) with ML-KEM (August 2024), despite making precisely no changes to the designs. The IETF should have an internal post-mortem on this, but I doubt we’ll see one My kingdom for a standards body that…

I think the anti-hybrid argument the article makes is clearly wrong. Even if CRQCs existed today, we still should be using hybrid algorithms because even once CRQCs exist, they will be slow, expensive, and power hungry for at least a decade. The hybrid algorithms at a minimum make the cost of any attack ~$1M, which is way better than half of the PQC algorithms that made it to the 3rd stage of the PQC competition (2 of them can be broken on a laptop)

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

#45
Yeah, sounds like it's time to take this very seriously. Sobering article to read, practical and to the point on risk posture. One brief paragraph though that I think deserves extra emphasis and I don't see in the comments here yet:

>In symmetric encryption, we don’t need to do anything, thankfully

This is valuable because it does offer a non-scalable but very important extra layer that a lot of us will be able to implement in a few important places today, or could have for awhile even. A lot of people and organizations here may have some critical systems where they can make a meat-space-man-power vs security trade by virtue of pre-shared keys and symmetric encryption instead of the more convenient and scalable normal pki. For me personally the big one is WireGuard, where as of a few years ago I've been able to switch the vast majority of key site-to-site VPNs to using PSKs. This of course requires out of band, ie, huffing it on over to every single site, and manually sharing every single profile via direct link in person vs conveniently deployable profiles. But for certain administrative capability where the magic circle in our case isn't very large this has been doable, and it gives some leeway there as any traffic being collected now or in the future will be worthless without actual direct hardware compromise.

That doesn't diminish the importance of PQE and industry action in the slightest and it can't scale to everything, but you may have software you're using capable of adding a symmetric layer today without any other updates. Might be worth considering as part of low hanging immediate fruit for critical stuff. And maybe in general depending on organization and threat posture might be worth imagining a worst-case scenario world where symmetric and OTP is all we have that's reliable over long time periods and how we'd deal with that. In principle sneakernetting around gigabytes or even terabytes of entropy securely and a hardware and software stack that automatically takes care of the rough edges should be doable but I don't know of any projects that have even started around that idea.

PQE is obviously the best outcome, we ""just"" switch albeit with a lot of increase compute and changed assumptions in protocols pain, but we're necessarily going to be leaning on a lot of new math and systems that won't have had the tires kicked nearly as long as all conventional ones have. I guess it's all feeling real now.

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

#47
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…

His article specifically mentions that the threat is with the public key exchange, not the encryption that happens after the key exchange.

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

#48
post #43

Earlier quoted context omitted.

Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time…

> In both cases, you need to start moving now and gain little from trying to time the switchover. There are a number of "you"s here, including: - The SDOs specifying the algorithms (IETF mostly) - CABF adding the algorithms to the Baseline Requirements so they can be used in the WebPKI - The HSM vendors adding support for the algorithms - CAs adding PQ roots - Browsers accepting them - Sites deploying them This is a…

Yeah, that's an audience mismatch, this article is for "us." End users of cryptography, including website operators and passkey users (https://news.ycombinator.com/item?id=47664744) can't do much right now, because "we" still need to finish our side.

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

#49
post #36

We'll know it's been cracked when all the lost Bitcoins start to move.

Yep, I was looking into it and from what I understand:

- There is a dark outlook on Bitcoin as the community and devs can't seem to coordinate. Especially on what to do with the "Satoshi coins"

- Ethereum has a hard but clear path (pretty much full rewrite) with a roadmap [0]

- The highly optimized "fast chains" (Solana & co) are in a lot of trouble too.

It would be funny if Bitcoin the asset end up migrating to Ethereum as another erc20 token

- [0] https://pq.ethereum.org/

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

#50
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…

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 also something weird in the graph in https://bas.westerbaan.name/notes/2026/04/02/factoring.html. That graph suggests that even with the best error correction in the graph, it is impossible to factor RSA-4 with less then 10^4 qubits. Which seems very odd. At the same time, Scott Aaronson wrote: "you actually can now factor 6- or 7-digit numbers with a QC". Which in the graph suggests that error rate must be very low already or quantum computers with an insane number of qubits exist.

Something doesn't add up here.

Post reply on HN