Hacker Newsnew | past | comments | ask | show | jobs | submit | bwesterb's commentslogin

Scott used to be that guy.

The abacus thing is pretty funny, but it's dangerously uninformed. https://bas.westerbaan.name/notes/2026/04/02/factoring.html

Is there a better benchmark to use?

Honest question.

How can a lay person track the real word progress of quantum computers?


Most approaches have missing "capabilities" that can be tracked. Adam Zalcman lays them out for superconducting qubits here. https://westerbaan.name/~bas/rwpqc2026/adam.pdf

For the neutral atoms approach in particular there doesn't seem to be a clear capability missing anymore to building a full scale CRQC: each of the separate components has been demonstrated. Of course when they try to put everything together they'll undoubtedly hit unexpected issues with integration. Wish I could be a fly on the wall at those labs.


It'll be a 90/10 rule: 90% of the upgrades will be straightforward. It's important the 10% that'll be hard early. For many it's probably already too late.

QKD is cool and all, but it just doesn't scale to the whole Internet. https://blog.cloudflare.com/you-dont-need-quantum-hardware/

Where available, you can migrate. Even if PQ is not yet available it helps to:

1. Make sure your dependencies are up to date. Move to a recent version of your crypto libraries. 2. Make sure your server can install multiple certificates: you'll need that unless you control all your clients. 3. Automate certificate issuance as far as possible.

Also, what you can do now is to run the following wargame: assume the CRQC arrived. What's the business impact?

For the migration itself I see three parallel streams.

1. Main push of straight-forward cases (TLS, etc.) Might need to wait a bit for software support.

2. Hard cases: crypto baked into hardware; custom protocols; keys in tight spaces (JWT in URLs); etc. You need to bubble those up soon to make decisions on how to fix them.

3. External dependencies. Barely any vendor has a PQ roadmap, so asking now is probably early, but you can figure out what to do if they don't get their stuff ready in time.


We're almost done countering store-now/decrypt-later, but the biggest part of the job, post-quantum authentication, still remains. Like Google, we target 2029 to be done .

SSH is working on a drop-in as we speak. TLS is further along: most stacks already support X25519MLKEM768 (by default!) to counter store-now/decrypt-later. PQ certs are not widely supported yet, but that's being sped up as we speak.

When it's real, it's too late.


You sure? Defenders get funding if things break—not when they actually did their job.


Yeah, it's rough. Important to understand now for each product / system what the business impact is if it's not upgraded in time.


Agreed. The migrations that stall are usually missing an explicit owner for each TLS surface, not missing algorithms. Business impact is the forcing function once you know who gets paged.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: