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.
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.
They are large, but they're not that slow actually. We've been testing them for almost a decade now. I agree that rushing is bad. That's why we need to start moving now, so that we're not rushing even closer to the deadline.
> I could also be misremembering our conversation, but I thought you had said something like 2029 or 2030 in our 2020 conversation
Think that must've been around 2022. It'd have been me mentioning 2030 regulatory deadlines. So far progress in PQC adoption has been mostly driven by (expected) compliance. Now it'll shift to a security issue again.
> My concern is that there's so much human and financial capital behind quantum computing that the "experts" have lots of reason to try to convince you that it's going to happen any day now.
There've been alarmist publications for years. If it were just some physicists again, I'd have been sceptical. This is the security folks at Google pulling the alarm (among others.)
> [B]ut we also don't have any proof (existence or theoretical) that proves they are actually possible.
The theoretic foundation is pretty basic quantum mechanics. It'd be a big surprise if there'd be a blocker there. What's left is the engineering. The problem is that definite proof means an actual quantum computer... which means it's already too late.
> The other challenge is we don't know where BQP fits
This is philosophy. Even P=NP doesn't imply cryptography is hopeless. If the concrete cost between using and breaking is large enough (even if it's not asymptotically) we can have perfectly secure systems. But this is quite a tangent.
> Should we prepare for QC on the cryptography side?
A 10% chance it happens by 2030, means we'll need to migrate by 2029.
> it and ongoing in terms of slowing down worldwide communications
We've been working hard to make the impact negligible. For key agreement the impact is very small. And with Merkle Tree Certificates we also make the overhead for authentication negligible.
Leaf certificates don't last long, but root CAs do. An attacker can just mint new certs from a broken root key.
Hopefully many devices can be upgraded to PQ security with a firmware update. Worse than not receiving updates, is receiving malicious firmware updates, which you can't really prevent without upgrading to something safe first.
Waiting now means rushing even more close to the deadline! We added stats on origin support for post-quantum encryption. Not as much support as browsers of course, but better than I expected. Still a long road (and authentication!). https://radar.cloudflare.com/post-quantum
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.
The key will be 40x larger. Not that bad for the certs. It'll be about 15kB extra. Will depend on your use case if that's bad. For video it's fine. But not all browsing is video. At Cloudflare half of the QUIC connections we see transfer less than 8kB from server -> client total. On average 3-4kB of that is already certificates today. That'll probably be quite noticeable. https://blog.cloudflare.com/pq-2025/#do-we-really-care-about...
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.