Re the "Manhattan project in 1944" argument - I am very cautious about the "modulo engineering scaling" carve-out -- unlike the uranium manufacturing pipeline of World War 2, that involved massively scaling up a known process, on the face of it there's no uncontroversial process/architecture to scale up in this case.
On the face of it, even relatively "point-target" goals of this kind could take many decades if at all; GaN for blue diodes come in mind as an example of a field that was stuck for a generation -- until it wasn't.
As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?
I have another comment[1] on this post with more practical instructions, but the `ssh-keygen` is a good question. The cryptography community is still focused on migrating encryption/key exchange algorithms, for fear of data being captured today and decrypted in the future. So OpenSSH 10.0+ already enables ML-KEM by default.
SSH keys, on the other hand, are authentication and would require an online Quantum Computer to break, so we have more time. Authentication is also (usually) more complicated, so there are still disagreements on what to do with the Web PKI for example. To give you a concrete target, Google, Microsoft, and CloudFlare have self-imposed deadlines of 2029 for their PQC migrations.
In practice, PQC migration means updating your software, bugging your vendors to ensure they have this on their roadmaps, and making sure your own code is flexible in respect to algorithms used.
On a separate note, I've definetly been hearing worried murmurs about "harvest and decrypt" attacks along with post-quantum TEE slightly before the GCP paper, and I definetly think it appears a couple nation states are on track for a "quantum leap" by 2030 given the rate at which I've been hearing it within my network.
What is the biggest number factored using Shor's algorithm?
Last time I looked it was very unimpressive.
Edit: It's gotten worse. 21 from 2012. "Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog" say the factorization of 35 in 2019 actually failed.
> Sometimes these days, I'll survey the spectacular recent progress in fault-tolerance, 2-qubit gate fidelities, programmable hundred-qubit systems, etc., only to be answered with a sneer: "What's the biggest number that Shor's algorithm has factored? Still 15 after all these years? Haha, apparently the emperor has no clothes!" I've commented that this is sort of like dismissing the Manhattan Project as hopelessly stalled in 1944, on the ground that so far it hasn't produced even a tiny nuclear explosion... If there's a reason why you think it can't work beyond a certain scale, say so. But don't fixate on one external benchmark and ignore everything happening under the hood, if the experts are telling you that under the hood is where all the action now is, and your preferred benchmark is only relevant later.
> If there's a reason why you think it can't work beyond a certain scale, say so
I'm not saying it can't work. Just that in 14 years no one has managed to factor a larger number than 21. Seemingly focus has shifted to other factoring algorithms that don't have performance improvements over conventional computing.
I'm not the one implying that Shor's algorithm will breaking encryption in "a few years from now".
> dismissing the Manhattan Project as hopelessly stalled in 1944
Then again, there are enough examples of failed projects. Why should this be comparable to the Manhattan project? In 1944, it was only two years underway, whereas Shor's algorithm is over 30. Tons of articles have been published on quantum computing, while the A bomb was kept as secret as possible, making learning from other countries, sometimes even from colleagues, impossible. In 1942, an atomic explosion was still hypothetical, whereas quantum computing had its first commercial service 7 years ago. Etc.
So, while in principle lack of progress doesn't guarantee failure, a comparison to the Manhattan Project is stylistic bullshit.
I talked to a guy who did his doctoral degree on quantum computing and he was not worried at all. In fact he thought it was wildly overhyped, and like cold fusion, self driving cars, or string theory, always just around the corner. Just give us five more years and another grant, please.
So we know that quantum computers hold a real risk of being able to break a lot of encryption. We also know that changing cyphers is hard (because reasons)
But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?
> But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?
Migrate! The major TLS and OpenSSH applications already support PQC, for example.
1. Make sure you have the required dependencies (e.g., openssl 3.5+ is when a lot of PQC algorithms got support).
2. Make sure the client/server software is up to date (this might be all that's needed, e.g., OpenSSH 10.0+ enables PQC in-transit encryption by default, and so does Chrome 131+).
3. Enable PQC support in the configuration (e.g., "ssl_ecdh_curve X25519MLKEM768;" in Nginx).
If you are the developer of anything that's explicitly using RSA or ECC (or god forbid Diffie-Hellman), you can also migrate your own software, or at least make the algorithm selectable at initialization time instead of hardcoded. If you have vendors, ask them for their PQC migration roadmaps.
Note that with encrypted data you want to protect yourself against attackers that are capturing data today and waiting to break it in the future (Harvest-Now, Decrypt-Later). So migrating encryption is more urgent than migrating authentication.
The most important thing to realize about cryptography is that, for most methods short of a Vernam cipher or quantum key distribution, coded messages need to be treated as published with delay. Cipher text can be archived today and attacked years from now with currently undeveloped, unknown, or unpredicted resources/algorithms. Sure, perhaps nobody archived the cipher text and you're fine. You don't know that for sure. Your methods may be very strong but, if they're not provably immune to attack, you also don't know what the delay before publication truly is. It might be a very long time. It might not.
If you're transmitting credit card info that changes every few years and can be changed on demand, that's no big deal. If you're transmitting information that will remain sensitive for decades, the time to look for methods that would stand up to quantum computing was years ago. However, today is still better than years in the future. At the very least, you can choose what to send in encrypted form over public networks and what not to send.
There are people who will scoff at the notion of quantum computing ever developing to the point where it can make an impact. There are people who scoff at the effort and expense of QKD or good ol' spooks carrying briefcases full of one-time PADs. You might be right to listen to them. You might not be. It's a risk. Whether you, or your organization, can tolerate that risk is entirely dependent on you and yours.
I think lobby for saner defaults (tip of the hat to Steve Gibson's term "the tyranny of the default"), configuring one's GPG config to mark certain cyphers as insecure (to prevent downgrade attacks)... and have one's (chief) information security officer write those things down as policy and maybe have a yearly onboarding workshop teaching people why it's important.
TLS can already be setup to avoid store-now-decrypt-later PQC issues. That's available today, and should be implemented.
Use https://sslboard.com to inventory all your external TLS infrastructure and check for PQC readiness (creator here).
If you're a CTO, have a post quantum strategy: know what crypto you use and where it is, plan to migrate to post quantum secure ciphers over the next decade or so, or sooner if possible. If you're a lowly engineer, not very much unless you're specifically selecting technologies with crypto. In which case crypto agility (being able to switch out existing crypto when needed) is a good property to look for.
I'm sure eventually i'll eat my words - but Quantum still seems like a massive marketing gimmick. The technology itself is incredibly interesting, but it feels as if CERN began advertising itself as a marketing stunt - there's just something about the way I see quantum marketed + advertised right now that doesn't seem to align with reality.
I suppose in spirit of the article - it's as if the manhattan project in 1944 was telling the world that theoretically it's 6-12 months away from igniting the entire upper atmosphere.
Aaronson know his stuff but I am not sure he hasn’t considered the fact that, in this current hype cycle, the quantum researchers breathlessly reporting to him on a breakthrough just around the corner are just lying to him and themselves.
I have been hearing about one more technical hurdle to solve before quantum algorithms become feasible since before I graduated. That was in 1996.
This is true, practical quantum computing is always "just a couple of years away".
At the same time, moving to more secure encryption really isn't difficult. How many times have algorithms been deprecated over the past 20 or so years? It's time to do it again.
Let's just make sure that the NSA hasn't worked in any backdoors. At latest since Snowdon, anything they work on is suspect.
There is no clear evidence that the risk of "a practical post quantum computer would arrive in the next 5 years" is greater than "post quantum scheme X is broken" for any scheme X. The only way to go is hybridation and it is quite hard from an engineering point apparently.
And in the process immediately convert huge numbers of devices into ewaste. Then check the excuse calendar again for tomorrow's reason to deprecate yet another batch of "legacy" ciphers from openSSL.
Quantum correction algorithms (that would allow factoring of thousands of digits) begin to work when the gate fidelity and other parameters are above certain threshold.
The Boy Who Cried Wolf is a story about a boy who have seen a wolf, successfully threatened the wolf away by causing a commotion in a disbelieving village. One day the disbelieving village refused to show up, boy was eaten and thus proven correct.
But as it happens in real life politics too, people who were just proven they were wrong continued to blame the boy.
The story is told from the point of view of a villagers trying to hide their culpability by blaming the victim.
> if quantum computers start breaking cryptography a few years from now, don’t you dare come to this blog and tell me that I failed to warn you. This post is your warning.
If quantum computers broke cryptography I think going to some guy's blog and complaining that he failed to warn me would be pretty low down on my todo list
Re the "Manhattan project in 1944" argument - I am very cautious about the "modulo engineering scaling" carve-out -- unlike the uranium manufacturing pipeline of World War 2, that involved massively scaling up a known process, on the face of it there's no uncontroversial process/architecture to scale up in this case.
On the face of it, even relatively "point-target" goals of this kind could take many decades if at all; GaN for blue diodes come in mind as an example of a field that was stuck for a generation -- until it wasn't.
As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?
I have another comment[1] on this post with more practical instructions, but the `ssh-keygen` is a good question. The cryptography community is still focused on migrating encryption/key exchange algorithms, for fear of data being captured today and decrypted in the future. So OpenSSH 10.0+ already enables ML-KEM by default.
SSH keys, on the other hand, are authentication and would require an online Quantum Computer to break, so we have more time. Authentication is also (usually) more complicated, so there are still disagreements on what to do with the Web PKI for example. To give you a concrete target, Google, Microsoft, and CloudFlare have self-imposed deadlines of 2029 for their PQC migrations.
In practice, PQC migration means updating your software, bugging your vendors to ensure they have this on their roadmaps, and making sure your own code is flexible in respect to algorithms used.
[1]: https://news.ycombinator.com/item?id=47959556
Cloudflare should have finished it's PQC migration already.
That's true for their CDN (https://blog.cloudflare.com/post-quantum-for-all/), but there's a lot more to do, with a 2029 target (https://blog.cloudflare.com/post-quantum-roadmap/).
Ah yep. Good callout.
On a separate note, I've definetly been hearing worried murmurs about "harvest and decrypt" attacks along with post-quantum TEE slightly before the GCP paper, and I definetly think it appears a couple nation states are on track for a "quantum leap" by 2030 given the rate at which I've been hearing it within my network.
It's still being implemented or defined.
The worry about "harvest and decrypt" in a 5 year timeframe is primarily from a nation state/natsec perspective.
If you are being targeted by a nation state as a line level engineer, harvest and decrypt is the least of your worries.
> Shor of Damocles
What is the biggest number factored using Shor's algorithm?
Last time I looked it was very unimpressive.
Edit: It's gotten worse. 21 from 2012. "Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog" say the factorization of 35 in 2019 actually failed.
https://eprint.iacr.org/2025/1237
I will let Scott Aaronson speak. (See https://scottaaronson.blog/?p=9668)
> Sometimes these days, I'll survey the spectacular recent progress in fault-tolerance, 2-qubit gate fidelities, programmable hundred-qubit systems, etc., only to be answered with a sneer: "What's the biggest number that Shor's algorithm has factored? Still 15 after all these years? Haha, apparently the emperor has no clothes!" I've commented that this is sort of like dismissing the Manhattan Project as hopelessly stalled in 1944, on the ground that so far it hasn't produced even a tiny nuclear explosion... If there's a reason why you think it can't work beyond a certain scale, say so. But don't fixate on one external benchmark and ignore everything happening under the hood, if the experts are telling you that under the hood is where all the action now is, and your preferred benchmark is only relevant later.
> If there's a reason why you think it can't work beyond a certain scale, say so
I'm not saying it can't work. Just that in 14 years no one has managed to factor a larger number than 21. Seemingly focus has shifted to other factoring algorithms that don't have performance improvements over conventional computing.
I'm not the one implying that Shor's algorithm will breaking encryption in "a few years from now".
> dismissing the Manhattan Project as hopelessly stalled in 1944
Then again, there are enough examples of failed projects. Why should this be comparable to the Manhattan project? In 1944, it was only two years underway, whereas Shor's algorithm is over 30. Tons of articles have been published on quantum computing, while the A bomb was kept as secret as possible, making learning from other countries, sometimes even from colleagues, impossible. In 1942, an atomic explosion was still hypothetical, whereas quantum computing had its first commercial service 7 years ago. Etc.
So, while in principle lack of progress doesn't guarantee failure, a comparison to the Manhattan Project is stylistic bullshit.
I talked to a guy who did his doctoral degree on quantum computing and he was not worried at all. In fact he thought it was wildly overhyped, and like cold fusion, self driving cars, or string theory, always just around the corner. Just give us five more years and another grant, please.
Meanwhile Waymo has 200 million autonomous miles under its belt.
Waymo had millions in 2015.
Waymo doesn't seem to know it.
https://waymo.com/research/safety-performance-of-the-waymo-r...
> Waymo’s rider-only ride-hailing operations reached its first one million rider-only miles on January 21, 2023
I said this about LLMs a few years ago, and now here we are.
Yeah 70 years ago right.
Ok, maybe I'm missing something here.
So we know that quantum computers hold a real risk of being able to break a lot of encryption. We also know that changing cyphers is hard (because reasons)
But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?
> But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?
Migrate! The major TLS and OpenSSH applications already support PQC, for example.
1. Make sure you have the required dependencies (e.g., openssl 3.5+ is when a lot of PQC algorithms got support).
2. Make sure the client/server software is up to date (this might be all that's needed, e.g., OpenSSH 10.0+ enables PQC in-transit encryption by default, and so does Chrome 131+).
3. Enable PQC support in the configuration (e.g., "ssl_ecdh_curve X25519MLKEM768;" in Nginx).
If you are the developer of anything that's explicitly using RSA or ECC (or god forbid Diffie-Hellman), you can also migrate your own software, or at least make the algorithm selectable at initialization time instead of hardcoded. If you have vendors, ask them for their PQC migration roadmaps.
Note that with encrypted data you want to protect yourself against attackers that are capturing data today and waiting to break it in the future (Harvest-Now, Decrypt-Later). So migrating encryption is more urgent than migrating authentication.
The most important thing to realize about cryptography is that, for most methods short of a Vernam cipher or quantum key distribution, coded messages need to be treated as published with delay. Cipher text can be archived today and attacked years from now with currently undeveloped, unknown, or unpredicted resources/algorithms. Sure, perhaps nobody archived the cipher text and you're fine. You don't know that for sure. Your methods may be very strong but, if they're not provably immune to attack, you also don't know what the delay before publication truly is. It might be a very long time. It might not.
If you're transmitting credit card info that changes every few years and can be changed on demand, that's no big deal. If you're transmitting information that will remain sensitive for decades, the time to look for methods that would stand up to quantum computing was years ago. However, today is still better than years in the future. At the very least, you can choose what to send in encrypted form over public networks and what not to send.
There are people who will scoff at the notion of quantum computing ever developing to the point where it can make an impact. There are people who scoff at the effort and expense of QKD or good ol' spooks carrying briefcases full of one-time PADs. You might be right to listen to them. You might not be. It's a risk. Whether you, or your organization, can tolerate that risk is entirely dependent on you and yours.
This is what Cloudflare[1] is doing.
[1] https://blog.cloudflare.com/post-quantum-roadmap/
I think lobby for saner defaults (tip of the hat to Steve Gibson's term "the tyranny of the default"), configuring one's GPG config to mark certain cyphers as insecure (to prevent downgrade attacks)... and have one's (chief) information security officer write those things down as policy and maybe have a yearly onboarding workshop teaching people why it's important.
TLS can already be setup to avoid store-now-decrypt-later PQC issues. That's available today, and should be implemented. Use https://sslboard.com to inventory all your external TLS infrastructure and check for PQC readiness (creator here).
If you're a CTO, have a post quantum strategy: know what crypto you use and where it is, plan to migrate to post quantum secure ciphers over the next decade or so, or sooner if possible. If you're a lowly engineer, not very much unless you're specifically selecting technologies with crypto. In which case crypto agility (being able to switch out existing crypto when needed) is a good property to look for.
"The Shor of Damocles" - what a metaphor.
I thought it was a typo at first but wikipedia explained:
The Sword of Damocles is an ancient Greek moral anecdote, an allusion to the imminent and ever-present peril faced by those in positions of power.
Shor's algorithm is a quantum algorithm for finding the prime factors of an integer
> the Shor of Damocles
Perfect.
I'm sure eventually i'll eat my words - but Quantum still seems like a massive marketing gimmick. The technology itself is incredibly interesting, but it feels as if CERN began advertising itself as a marketing stunt - there's just something about the way I see quantum marketed + advertised right now that doesn't seem to align with reality.
> * it feels as if CERN began advertising itself as a marketing stunt*
Quantum AI harvesting antimatter
I suppose in spirit of the article - it's as if the manhattan project in 1944 was telling the world that theoretically it's 6-12 months away from igniting the entire upper atmosphere.
Aaronson know his stuff but I am not sure he hasn’t considered the fact that, in this current hype cycle, the quantum researchers breathlessly reporting to him on a breakthrough just around the corner are just lying to him and themselves.
I have been hearing about one more technical hurdle to solve before quantum algorithms become feasible since before I graduated. That was in 1996.
This is true, practical quantum computing is always "just a couple of years away".
At the same time, moving to more secure encryption really isn't difficult. How many times have algorithms been deprecated over the past 20 or so years? It's time to do it again.
Let's just make sure that the NSA hasn't worked in any backdoors. At latest since Snowdon, anything they work on is suspect.
There is no clear evidence that the risk of "a practical post quantum computer would arrive in the next 5 years" is greater than "post quantum scheme X is broken" for any scheme X. The only way to go is hybridation and it is quite hard from an engineering point apparently.
There is evidence of the opposite: graph singular isogeny mumbo jumbo algorithm was proven to be easily broken on an ordinary computer.
Hybrid encryption is as simple as running one encryption and then the other. Problem is mostly that post quantum keys are large.
And in the process immediately convert huge numbers of devices into ewaste. Then check the excuse calendar again for tomorrow's reason to deprecate yet another batch of "legacy" ciphers from openSSL.
The sooner we start making devices ready for better encryption systems, the fewer devices will be wasted.
Are you saying this because it's an evergreen joke or because you really think there hasn't been meaningful progress in the field since 1996?
Duke Nukem Forever was release fifteen years ago. Some things never happen until they suddenly do.
The wolf really does eat the boy at the end of The Boy Who Cried Wolf.
But Duke Nukem was developed with visible progress.
We are still not factoring 21, let alone 35, let alone numbers with thousands of digits.
Quantum correction algorithms (that would allow factoring of thousands of digits) begin to work when the gate fidelity and other parameters are above certain threshold.
> gate fidelity and other parameters are above certain threshold
A threshold that might be beyond what the physical properties of our universe allow. It is still unclear.
The Boy Who Cried Wolf is a story about a boy who have seen a wolf, successfully threatened the wolf away by causing a commotion in a disbelieving village. One day the disbelieving village refused to show up, boy was eaten and thus proven correct.
But as it happens in real life politics too, people who were just proven they were wrong continued to blame the boy.
The story is told from the point of view of a villagers trying to hide their culpability by blaming the victim.
quantum computers will flourish the same day that fusion does.
Tl;dr:
> if quantum computers start breaking cryptography a few years from now, don’t you dare come to this blog and tell me that I failed to warn you. This post is your warning.
If quantum computers broke cryptography I think going to some guy's blog and complaining that he failed to warn me would be pretty low down on my todo list