←back to thread

Willow quantum chip demonstrates verifiable quantum advantage on hardware

(blog.google)
429 points AbhishekParmar | 5 comments | 22 Oct 25 15:16 UTC | HN request time: 0.001s | source
Show context
Imnimo ◴[22 Oct 25 15:37 UTC] No.45670761[source]▶
As with any quantum computing news, I will wait for Scott Aaronson to tell me what to think about this.
replies(6): >>45670868 #>>45670978 #>>45671067 #>>45671079 #>>45671833 #>>45672034 #
lisper ◴[22 Oct 25 15:50 UTC] No.45670978[source]▶
Why wait? Just go read the paper:

https://www.nature.com/articles/s41586-025-09526-6

In the last sentence of the abstract you will find:

"These results ... indicate a viable path to practical quantum advantage."

And in the conclusions:

"Although the random circuits used in the dynamic learning demonstration remain a toy model for Hamiltonians that are of practical relevance, the scheme is readily applicable to real physical systems."

So the press release is a little over-hyped. But this is real progress nonetheless (assuming the results actually hold up).

[UPDATE] It should be noted that this is still a very long way away from cracking RSA. That requires quantum error correction, which this work doesn't address at all. This work is in a completely different regime of quantum computing, looking for practical applications that use a quantum computer to simulate a physical quantum system faster than a classical computer can. The hardware improvements that produced progress in this area might be applicable to QEC some day, this is not direct progress towards implementing Shor's algorithm at all. So your crypto is still safe for the time being.

replies(4): >>45671003 #>>45671037 #>>45671611 #>>45671618 #
ransom1538 ◴[22 Oct 25 15:51 UTC] No.45671003[source]▶
SO... BTC goes to zero?
replies(5): >>45671041 #>>45671043 #>>45671120 #>>45671360 #>>45672639 #
deliriumchn ◴[22 Oct 25 15:54 UTC] No.45671041[source]▶
no, not really, PQC is already being discussed in pretty much every relevant crypto thing for couple years alearady and there are multiple PQC algos ready to protect important data in banking etc as well
replies(1): >>45671599 #
cyberpunk ◴[22 Oct 25 16:29 UTC] No.45671599[source]▶
I don’t really understand the threat to banking. Let’s say you crack the encryption key used in my bank between a java payment processing system and a database server. You can’t just inject transactions or something. Is the threat that internal network traffic could be read? Transactions all go to clearing houses anyway. Is it to protect browser->webapp style banking? those all use ec by now anyway, and even if they don’t how do you mitm this traffic?

Where is the exact threat?

replies(3): >>45671825 #>>45671955 #>>45672073 #
1. conradev ◴[22 Oct 25 16:47 UTC] No.45671825[source]▶
The big threat is passively breaking TLS, so it’s browser traffic. Or, any internet traffic?
replies(1): >>45671954 #
2. cyberpunk ◴[22 Oct 25 16:55 UTC] No.45671954[source]▶
Okay, but breaking that TLS (device->bank) would allow you to intercept the session keys and then decrypt the conversation. Alright, so now you can read I logged in and booked a transaction to my landlord or whatever. What else can you do? OTP/2FA code prevents you from re-using my credentials. Has it been demonstrated at all that someone who intercepts a session key is able to somehow inject into a conversation? It seems highly unlikely to me with TCP over the internet.

So we are all in a collective flap that someone can see my bank transactions? These are pretty much public knowledge to governments/central banks/clearing houses anyway -- doesn't seem like all that big a deal to me.

(I work on payment processing systems for a large bank)

replies(1): >>45672045 #
3. bawolff ◴[22 Oct 25 17:02 UTC] No.45672045[source]▶
> Has it been demonstrated at all that someone who intercepts a session key is able to somehow inject into a conversation? It seems highly unlikely to me with TCP over the internet.

if you can read the TLS session in general, you can capture the TLS session ticket and then use that to make a subsequent connection. This is easier as you dont have to be injecting packets live or make inconvinent packets disappear.

replies(1): >>45672194 #
4. cyberpunk ◴[22 Oct 25 17:15 UTC] No.45672194{3}[source]▶
It seems like detecting a re-use like this should be reasonably easy, it would not look like normal traffic and we could flag this to our surveillance systems for additional checks on these transactions. In a post quantum world, this seems like something that would be everywhere anyway (and presumably, we would be using some other algo by then too).

Somehow, I'm not all that scared. Perhaps I'm naive.. :}

replies(1): >>45676928 #
5. bawolff ◴[23 Oct 25 00:41 UTC] No.45676928{4}[source]▶
> It seems like detecting a re-use like this should be reasonably easy, it would not look like normal traffic

I don't see why it wouldn't look like normal traffic.

> Somehow, I'm not all that scared. Perhaps I'm naive.. :}

We're talking about an attack that probably won't be practical for another 20 years , which already has counter measures that are in testing right now. Almost nobody should be worried about it.