I find the editorialized title misleading. They trapped 17000 atom pairs in an optical lattice and demonstrated a high-fidelity quantum gate between the atoms of each pair in parallel. There is no interaction between the atoms of different pairs and no individual control. The experiment demonstrates a very robust gate scheme, but is a long way from a programmable computer.
... and room temperature superconductors! If only we could sort out the feasibility, interdependencies, and priorities, but we just don't know, or well, I just don't know haha.
What is overhyped about: "A new trick brings stability to quantum operations". Are people complaining about the HN title as if it's the article's title?
I have questions. Is he attempting to build a quantum gate array? Seems kind of unfair to compare one person's efforts with a well-established university, if so. :P
sure this isn't a 17k qubit quantum computer, but it's a step in that direction
and this isn't the only news falling under "this is moving faster then expected"
just one in many which scream "time to take it serious, deadline 2029 try earlier"
---
a year or so(?) ago some investments happened, which made only sense if there had been some unpublished break through in quantum computer hardware (through you never can exclude foolish absurd high Risiko investments). (Sadly I didn't bookmark/safe the relevant articles/analysis, so take with a grain of salt.)
then more recently, google researchers had some break through wrt. quantum algorithms. It can now be generally assumed that 10k qubits (in the right setup) are enough to break 256 elliptic curve cryptography (or 2048bit RSA) _in minutes_!
There where also other hardware breakthrough published, and error correction break throughs etc.
The general consensus of people more knowledgeable in this field then me seems to be going in the direction that you must _finish fully migrate to post quantum cryptography by 2029_.
Note that this isn't a "100% guarantee there are cable quantum computers in 2030", but a "the chance of this happening is too high to not be prepared by then".
Also that is mainly true for webpki, TLS, cloud infrastructure/deployment systems, code signing, etc.
Overall:
- from a academic/paper background 2029 seems to be the deadline to finish migrating to post quantum cryptography
- claudflare agrees and has moved up it's internal deadline to 2029
- same for Google, Google also seem to have prioritized quantum secure authentication over harvest now/decrypt later protections. Which IMHO implies they take that deadline quite serious.
- IBM expect some "moonshot" attacks against high value targets already in 2029 (i.e. ~one year earlier) instead of 2030.
___
Through overall what does that mean for most people?
- If you run some small low security service then probably for now nothing much. But make sure you can move to pq if the tooling (webpki, TLS, etc.) starts supporting it and keep an eye on the topic.
- For webpki, TLS and co having well working and by default supported pq cryptography is paramount. This tech isn't just powering the secure web, it's used far beyond and if broken might be enough to take over large parts of whole cloud providers.
- If you have some very sensitive material, where it's a big problem if it leaks even years later, then you have a problem. Because you probably should have already migrated to post quantum cryptography 1-2 years ago ... Note that symmetric encryption is mostly unaffected. Sure there are a lot of people saying it's "slashed in half" (e.g. 128bit => 64bit) but luckily that isn't fully true. I personally still would go with 256bit where viable, as often there is little reason not to do so. BUT a lot of the ways of sharing/accessing/deriving that secure symmetric key use cryptography which should be assumed to be broken soon.
- for VPNs if they allow complementing the asym. crypto with a symmetric key do that now (e.g. wireguard pre-shared key). But that is for many use cases a hen/egg issue as how do you securely exchange the pre-shared key? So look out for changes in the tooling/ecosystem.
- for DevOps, look out for changes in the ecosystem especially webpki/TLS/certs and look out for tools which have a high chance to not mitigate in time
- for Devs post quantum cryptography often looks like it could "just slot in" but that often isn't fully the case due to very different key sizes and performance characteristics. Look out for it. Also making you system ready to migrate to pq-safety was a recommendation by NSA and pretty much any other national cyber security agency for years by now. Furthermore with the standardization of ML-KEM the recommendation shifted to using that where viable (potentially in a hybrid KEM). So if you now notice that you never bother to check/plane ahead you probably should give it some priority now as you may be found to have acted in neglect which could in unlucky cases turn into legal liabilities.
> “We can now make lots of swap gates with neutral atoms”, says Tilman Esslinger, “but of course we still need a few other ingredients to build a working quantum computer.”
yes, while this may not be a 17k qubit computer and has ways to go to get there the insights from it will likely help us to get there faster
and it's not the only "this is moving faster then expected new"
a year or so(?) ago some investments happen which make only sense if there had been some unpublished break through in hardware (through you never can exclude foolish absurd high Risiko investments)
then more recently google researchers had some break through wrt. quantum algorithms, it's not generally assumed that 10k qubits (in the right setup) are enough to break 256 elliptic curve cryptography (or 2048bit RSA) _in minutes_!
and there also where other breakthroughs quantum computer wrt. hardware
the general consensus of people more knowledgeable in this field seems to be going in the direction that you must _finish fully migrate to post quantum cryptography by 2029_.
Note that this isn't a "100% guarantee there are cable quantum computers in 2030", but a "the chance of this happening is too high to not be prepared by then".
Overall:
- from a academic/paper background 2029 seems to be the deadline to finish migrating to post quantum cryptography
- claudflare agrees and has moved up it's internal deadline to 2029
- same for Google, Google also seem to have prioritized quantum secure authentication over harvest now/decrypt later protections, which implies they are seriously worried about their authentication breaking potentially as early as 2030
- IBM expect some "moonshot" attacks against high value targets already in 2029
___
Through overall what does that mean for most people?
- if you run some small low security service then probably for now nothing, but make sure you can move to pq if the tooling (webpki, TLS, etc.) does
- for webpki, TLS and co having well working and by default supported pq cryptography is paramount
- if you have some very sensitive material where it's a big problem if it leaks even years later, then you have a problem because you probably should have already migrated to post quantum cryptography 1-2 years ago ... Note that symmetric encryption is mostly unaffected. Sure there are a lot of people saying it's "slashed in half" (e.g. 128bit => 64bit) but luckily that isn't fully true. I personally still would go with 256bit where viable, often there is little reason not to. BUT a lot of the ways of sharing that symmetric key use encryption which should be assumed to be broken soon.
- for VPNs if they allow complementing the asym. crypto with a symmetric key do that now (e.g. wireguard pre-shared key) but that is for many use cases a hen/egg issue as how do you securely exchange the pre-shared key? So look out for changes in the tooling/ecosystem.
- for DevOps, look out for changes in the ecosystem especially webpki/TLS/certs and look out for tools which have a high chance to not mitigate in time
- for Devs post quantum cryptography often looks like it could "just slot in" but that often isn't fully the case due to very different key sizes and performance characteristics. Look out for it. Also making you system ready to migrate to pq-safety was a recommendation by NSA and pretty much any other national cyber security agency for years by now. Furthermore with the standardization of ML-KEM the recommendation shifted to using that where viable (potentially in a hybrid KEM). So if you now notice that you never bother to check/plane ahead you probably should give it some priority now as you may be found to have acted in neglect which could in unlucky cases turn into legal liabilities.
It is still orders of magnitude away from breaking RSA 2048 even under the most optimistic assumptions. And qubits double waaay slower than transistors so far.
The “decade away” phenomenon comes from the fact that it’s basically impossible to time estimate innovation.
* I've worked with too many Sth Africans.
https://arxiv.org/abs/2507.22112
sure this isn't a 17k qubit quantum computer, but it's a step in that direction
and this isn't the only news falling under "this is moving faster then expected"
just one in many which scream "time to take it serious, deadline 2029 try earlier"
---
a year or so(?) ago some investments happened, which made only sense if there had been some unpublished break through in quantum computer hardware (through you never can exclude foolish absurd high Risiko investments). (Sadly I didn't bookmark/safe the relevant articles/analysis, so take with a grain of salt.)
then more recently, google researchers had some break through wrt. quantum algorithms. It can now be generally assumed that 10k qubits (in the right setup) are enough to break 256 elliptic curve cryptography (or 2048bit RSA) _in minutes_!
There where also other hardware breakthrough published, and error correction break throughs etc.
The general consensus of people more knowledgeable in this field then me seems to be going in the direction that you must _finish fully migrate to post quantum cryptography by 2029_.
Note that this isn't a "100% guarantee there are cable quantum computers in 2030", but a "the chance of this happening is too high to not be prepared by then".
Also that is mainly true for webpki, TLS, cloud infrastructure/deployment systems, code signing, etc.
Overall:
- from a academic/paper background 2029 seems to be the deadline to finish migrating to post quantum cryptography
- claudflare agrees and has moved up it's internal deadline to 2029
- same for Google, Google also seem to have prioritized quantum secure authentication over harvest now/decrypt later protections. Which IMHO implies they take that deadline quite serious.
- IBM expect some "moonshot" attacks against high value targets already in 2029 (i.e. ~one year earlier) instead of 2030.
___
Through overall what does that mean for most people?
- If you run some small low security service then probably for now nothing much. But make sure you can move to pq if the tooling (webpki, TLS, etc.) starts supporting it and keep an eye on the topic.
- For webpki, TLS and co having well working and by default supported pq cryptography is paramount. This tech isn't just powering the secure web, it's used far beyond and if broken might be enough to take over large parts of whole cloud providers.
- If you have some very sensitive material, where it's a big problem if it leaks even years later, then you have a problem. Because you probably should have already migrated to post quantum cryptography 1-2 years ago ... Note that symmetric encryption is mostly unaffected. Sure there are a lot of people saying it's "slashed in half" (e.g. 128bit => 64bit) but luckily that isn't fully true. I personally still would go with 256bit where viable, as often there is little reason not to do so. BUT a lot of the ways of sharing/accessing/deriving that secure symmetric key use cryptography which should be assumed to be broken soon.
- for VPNs if they allow complementing the asym. crypto with a symmetric key do that now (e.g. wireguard pre-shared key). But that is for many use cases a hen/egg issue as how do you securely exchange the pre-shared key? So look out for changes in the tooling/ecosystem.
- for DevOps, look out for changes in the ecosystem especially webpki/TLS/certs and look out for tools which have a high chance to not mitigate in time
- for Devs post quantum cryptography often looks like it could "just slot in" but that often isn't fully the case due to very different key sizes and performance characteristics. Look out for it. Also making you system ready to migrate to pq-safety was a recommendation by NSA and pretty much any other national cyber security agency for years by now. Furthermore with the standardization of ML-KEM the recommendation shifted to using that where viable (potentially in a hybrid KEM). So if you now notice that you never bother to check/plane ahead you probably should give it some priority now as you may be found to have acted in neglect which could in unlucky cases turn into legal liabilities.
and it's not the only "this is moving faster then expected new"
a year or so(?) ago some investments happen which make only sense if there had been some unpublished break through in hardware (through you never can exclude foolish absurd high Risiko investments)
then more recently google researchers had some break through wrt. quantum algorithms, it's not generally assumed that 10k qubits (in the right setup) are enough to break 256 elliptic curve cryptography (or 2048bit RSA) _in minutes_!
and there also where other breakthroughs quantum computer wrt. hardware
the general consensus of people more knowledgeable in this field seems to be going in the direction that you must _finish fully migrate to post quantum cryptography by 2029_.
Note that this isn't a "100% guarantee there are cable quantum computers in 2030", but a "the chance of this happening is too high to not be prepared by then".
Overall:
- from a academic/paper background 2029 seems to be the deadline to finish migrating to post quantum cryptography
- claudflare agrees and has moved up it's internal deadline to 2029
- same for Google, Google also seem to have prioritized quantum secure authentication over harvest now/decrypt later protections, which implies they are seriously worried about their authentication breaking potentially as early as 2030
- IBM expect some "moonshot" attacks against high value targets already in 2029
___
Through overall what does that mean for most people?
- if you run some small low security service then probably for now nothing, but make sure you can move to pq if the tooling (webpki, TLS, etc.) does
- for webpki, TLS and co having well working and by default supported pq cryptography is paramount
- if you have some very sensitive material where it's a big problem if it leaks even years later, then you have a problem because you probably should have already migrated to post quantum cryptography 1-2 years ago ... Note that symmetric encryption is mostly unaffected. Sure there are a lot of people saying it's "slashed in half" (e.g. 128bit => 64bit) but luckily that isn't fully true. I personally still would go with 256bit where viable, often there is little reason not to. BUT a lot of the ways of sharing that symmetric key use encryption which should be assumed to be broken soon.
- for VPNs if they allow complementing the asym. crypto with a symmetric key do that now (e.g. wireguard pre-shared key) but that is for many use cases a hen/egg issue as how do you securely exchange the pre-shared key? So look out for changes in the tooling/ecosystem.
- for DevOps, look out for changes in the ecosystem especially webpki/TLS/certs and look out for tools which have a high chance to not mitigate in time
- for Devs post quantum cryptography often looks like it could "just slot in" but that often isn't fully the case due to very different key sizes and performance characteristics. Look out for it. Also making you system ready to migrate to pq-safety was a recommendation by NSA and pretty much any other national cyber security agency for years by now. Furthermore with the standardization of ML-KEM the recommendation shifted to using that where viable (potentially in a hybrid KEM). So if you now notice that you never bother to check/plane ahead you probably should give it some priority now as you may be found to have acted in neglect which could in unlucky cases turn into legal liabilities.
:-D
This title is misleading.