Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

31–40 of 260 posts

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

#31

Earlier quoted context omitted.

That's not a rebuttal. The post references the paper and a rebuttal to it from an expert in the field.

Damn. It's like I insulted Vault. Also, I went over Filippo's post again and still can't see where it references the Gutmann / Neuhaus paper. Are we talking about the same post?

From the abstract:

> This paper presents implementations that match and, where possible, exceed current quantum factorisation records using a VIC-20 8-bit home computer from 1981, an abacus, and a dog.

From the link:

> 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[1]. As Scott Aaronson said[2]:

> > 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?”

[1]: https://bas.westerbaan.name/notes/2026/04/02/factoring.html

[2]: https://scottaaronson.blog/?p=9665#comment-2029013

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

#34

Building out a supercomputer capable of breaking cryptography is exactly the kind of thing I expect governments to be working on now. It is referenced in the article, but the analogy to the Manhattan Project is clear. Prior to 1940 it was known that clumping enough fissile material together could produce an explosion. There were engineering questions around how to purify uranium and how to actually construct the weap…

The Manhattan project employed some significant % of all of America. A project of that scale will likely never happen again. It was also about far more than the science. It was about industrializing the entire production process and creating industrial capability that simply did not exist before.

My comment was not limited to the U.S. government.

And the Manhattan Project cost $30B in today’s money. Compared with some of the numbers Congress has allocated recently, I’d call that a bargain.

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

#37
post #20

It should be noted that if indeed there has not remained much time until a usable quantum computer will become available, the priority is the deployment of FIPS 203 (ML-KEM) for the establishment of the secret session keys that are used in protocols like TLS or SSH. ML-KEM is intended to replace the traditional and the elliptic-curve variant of the Diffie-Hellman algorithm for creating a shared secret value. When FIP…

> The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them. This very much exists. In particular, the…

Yes, though we do know how to solve this problem by using hash-based timestamping systems. See: https://link.springer.com/article/10.1007/BF00196791

Of course, the modern version of this is putting the timestamp and a hash of the signature on the blockchain.

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

#38
post #30

Earlier quoted context omitted.

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

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 the switchover.

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

#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 thing we have right now is that quantum computers are absolutely hopeless doing anything with RSA and as far as I know, nobody even tried EC. And that state of the art has not moved much in the last decade.

And then suddenly, in a few years there will be a quantum computer that can break all of the classical public key crypto that we have.

This kind of stuff might happen in a completely new field. But people have been working on quantum computers for quite a while now.

If this is easy enough that in a few years you can have a quantum computer that can break everything then people should be able to build something in a lab that breaks RSA 256. I'd like to see that before jumping to conclusions on how well this works.

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

#40
post #33

This would also be a good time for certain governments to knowingly push broken PQ KE standards while there is a panicked rush to get PQ tech in place.

Remember that the entities most likely to heed those governments recommendations are those providing services to said government and its military.

I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely.

See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for whether the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.

Post reply on HN