Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

51–60 of 260 posts

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

#51
I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good.

Age should be using 256 bit file keys, and default to PC keys in asymmetric mode.

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

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

IMO the idea that NSA only uses NOBUS backdoors is obviously false (see for example DES's 56 bit key size). The NSA is perfectly capable of publicly calling for an insecure algorithm and then having secret documentation to not use it for anything important.

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

#53
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 o…

Is it?

Your reasoning relies on this being true:

> [CRQCs] will be slow, expensive, and power hungry for at least a decade

How could you know that? What if it was 5 years? 1 year? 6 months?

I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.

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

#54
post #50

Earlier quoted context omitted.

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 al…

You can already factor a 6 digit number with a QC, but not with an algorithm that scales polynomially. The graph linked is for optimized variants of Shor's algorithm.

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

#56

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…

> There were engineering questions around how to purify uranium and how to actually construct the weapon etc. But the phenomenon was known.

FWIW, constructing a weapon with highly enriched uranium is, relatively, simple. At the time, the choice was made to use a gun-type weapon that shot a projectile of highly enriched uranium into a a "target" of highly enriched uranium. The scientists were so sure it would work that the design didn't necessitate a live test. This was "little boy", which was eventually dropped on Hiroshima.

Fat Man utilized plutonium which required an implosion to compress the fissile material that would set off the chain reaction. This is a much more complex undertaking, but it's much more efficient. Namely, you need much less fissile material, and more of that fissile material is able to participate in the chain reaction. This design is what allows for nuclear tipped missiles. The same principles can be applied to a U-235 based weapon as well.

The implosion based design is super interesting to read about. One memorable aspect is that the designers realized that applying a tamper of uranium (U-238) around the fissile material allows for significant improvement in yield. The chain reaction is exponential, so the few extra nanoseconds that the uranium keeps the fissile material together leads to significant increase in yield.

https://en.wikipedia.org/wiki/Little_Boy

https://en.wikipedia.org/wiki/Fat_Man

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

#57
post #51

I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good. A…

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

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

#60

Earlier quoted context omitted.

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 o…

Is it? Your reasoning relies on this being true: > [CRQCs] will be slow, expensive, and power hungry for at least a decade How could you know that? What if it was 5 years? 1 year? 6 months? I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.

The absolute low end of cost of a QC is the cost of an MRI machine ~100k-400k (cost of cooling the computer to super low temps). Sure we expect QCs to get faster and cheaper over time, but putting 100% faith in the security of the PQC algorithms seems like a bad idea with no upside.
Post reply on HN