The BLAKE3 angle here is interesting — we switched from SHA-256 to BLAKE3 for hash-chaining in a local multi-agent security orchestrator precisely because of this kind of forward-looking pressure. Not the same threat model, but the instinct to not build new systems on classical primitives feels validated by this post.
A cryptography engineer's perspective on quantum computing timelines
201–210 of 260 posts
Re: A cryptography engineer's perspective on quantum computing timelines
#202Earlier quoted context omitted.
Fault tolerance is a hard problem, assembling qubits for simultaneous gate operations is another hard problem. There are several dozen others. It is exceptionally unlikely CRQC will be achieved in our lifetimes, if ever. The closer example is economically-viable fusion power production, which today has better odds than CRQC but remains solidly in the "maybe" zone after decades of global investment. Even though fusion…
Fusion also came to my mind but after thinking about it for longer I think it's a bad argument. The challenge with fusion is mostly around scale and efficiency to make it competitive against other energy sources (and net energy positive in the first place). For CRQC it doesn't matter if they're massive expensive energy monsters. Even being able to break a single chosen key is enough to be a problem and once you can d…
They're just different definitions of success.
For fusion the bar is "economically viable", in the current discussion for QC the bar is "cryptographically relevant".
They are comparable in that to meet either criteria, a variety of unsolved engineering challenges need to be overcome. For both, some of those problems have no clear and obvious solutions to which a simple application of resources and time will achieve.
Currently unknown innovations are required, unknown unknowns lurk in the dark corners, and all projections are relying on the assumption such innovations will arrive in a timely fashion and the unknown unknowns will be harmless glitches.
Neither are likely impossible, but betting on timelines is a fools game. This isn't the NYT publishing man-made flight is a million years away 2 months before the Wright brothers flew at Kitty Hawk, waiting for the right conglomeration of otherwise sound engineering to materialize in one place. It's like saying level 5 self-driving cars are two years away, a perpetually delayed technology for which all problems are well known and no new innovations are imminent.
Re: A cryptography engineer's perspective on quantum computing timelines
#203> “Doesn’t the NSA lie to break our encryption?” No, the NSA has never intentionally jeopardized US national security with a non-NOBUS backdoor, and there is no way for ML-KEM and ML-DSA to hide a NOBUS backdoor. The most concrete issue for me, as highlighted by djb, is that when the NSA insists against hybrids, vendors like telecommunications companies will handwrite poor implementations of ML-KEM to save memory/CPU…
Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argu…
Maybe your motives are benevolent, but you're arguing two things:
1) We can broadly trust the US government 2) We should adopt new encryption partly designed and funded by the US government, and get rid of the battle tested encryption that they seem not to be able to break
Forgive me for being somewhat suspicious of your motives here
Re: A cryptography engineer's perspective on quantum computing timelines
#204This is the first well reasoned write up which makes me walk back from my "QC is irrelevant, and RSA is fine" position a bit. Well done! Thank you for putting this into terms a skeptic can relate to and understand. It helped me re-frame my thinking on risks here.
A huge part of that, for me, was this from Scott Aaronson: > 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?” That quote, alone, removed a lot of assumptions I had been carrying around.
That quote alone proves that the author knows nothing about nuclear physics.
There is a critical flux/density/mass threshold for nuclear bombs. You can create small nuclear explosions with particle accelerators, which is how it all started. You just cannot scale those accelerators to anything macroscopic. But the microscopic explosions where done very very early, otherwise nobody would have had the necessary data to later extrapolate this to larger scales.
The interesting question after that first discovery of fission was only about how large the critical density or mass would be for a self-sustaining reaction. But as soon as you knew the critical mass, and had enough fissile material to go over that threshold, things became feasible, and easier with even more material.
Quantum computing doesn't have such a threshold, quite the opposite. As far as we know, larger problem sizes and larger numbers of qbits make things harder. Quantum error correction only changes the exponent in that relation.
Re: A cryptography engineer's perspective on quantum computing timelines
#205Earlier quoted context omitted.
> Since then, public cryptographic research has been ahead or even with state work. How can we know that? > Who knows what is happening inside the NSA or military facilities? Couldn't have NSA found an issue with ML-KEM and try to convince people to use it exclusively (not in hybrid scheme with ECC)?
Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm? What's the PQC construction you couldn't say either thing about?
> Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm?
Could, but they did not do that. So, the question is to be stated: Why?
Re: A cryptography engineer's perspective on quantum computing timelines
#206Earlier 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?
Use PSK signature.
Re: A cryptography engineer's perspective on quantum computing timelines
#207It 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…
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 you have to repeat it uncritically.
Re: A cryptography engineer's perspective on quantum computing timelines
#208Earlier 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…
I’ve worked with Bas. I respect him, but he is definitely a QC maximalist in a way. At the very least he believes that caution suggests the public err on the side of believing we will build them. The actual challenge is we still don’t know if we can build QC circuits that factorize faster than classical both because the amount of qubits has gone from ridiculously impossible to probably still impossible AND because we…
Don't recognise you from your username, but thanks for the respect. (Update: ah, Vitali! Nice to hear from you.)
If you look back at my writing from 2025 and earlier, I'm on the conservative end of Q-day estimates: 2035 or later. My primary concern then is that migrations take a lot of time: even 2035 is tight.
I'm certainly not an expert on building quantum computers, but what I hear from those that are worries me. Certainly there are open challenges for each approach, but that list is much shorter now than it was a few years ago. We're one breakthrough away from a CRQC.
Re: A cryptography engineer's perspective on quantum computing timelines
#209I think people have to be extremely careful with this kind of opinion. In particular seeing such a push for post-quantum crypto while the current state of the art for quantum factorisation is 15 and 21 and the fact that current assumptions (for KEM in particular) are clearly not as studied as dlog. It's maybe good to remember that SIDH was broken in polynomial time by a classical computer 3 years ago... I'm really co…
The largest number factorised on a quantum computer is 8,219,999 on a D-Wave machine (a quantum annealer, so not capable of running Shor's, but capable of being an actual shipping product you can use, unlike gate model machines). https://www.nature.com/articles/s41598-024-53708-7 > Overall, 8,219,999 = 32,749 × 251 was the highest prime product we were able to factorize within the limits of our QPU resources. To the…
You should read the article you posted before you write a comment. Hint: check P_F=0 in tables 2, 3 and 4.
"Factored" is doing a lot of lifting here and is borderline deceptive. Plenty of researchers have long ago pointed out that this won't scale, see M Mosca for reference.
Re: A cryptography engineer's perspective on quantum computing timelines
#210Earlier quoted context omitted.
It's definitely not that "The research on lattice-based crypto is still young compared to EC/RSA."
Perhaps you would care to enlighten us ignorant plebs rather than taunting us? My understanding (obviously as a non expert) matches what cyberax wrote above. Is it not common wisdom that the pursuit of new and exciting crypto is an exercise filled with landmines? By that logic rushing to switch to the new shiny would appear to be extremely unwise. I appreciate the points made in the article that the PQ algorithms are…
[dead]