Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

Post reply on HN
Print view View original

131–140 of 260 posts

Re: A cryptography engineer's perspective on quantum computing timelines

#131

Post by Strilanc »

phicoh wrote: post #50
FiloSottile wrote: post #41

Earlier quoted context omitted.

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-toleran…

The thing is, producing the right isotopes of uranium is mostly a linear process. It goes faster as you scale up of course, but each day a reactor produces a given amount. If you double the number of reactors you produce twice as much, etc. There is no such equivalent for qubits or error correction. You can't say, we produce this much extra error correction per day so we will hit the target then and then. There is al…

> That graph suggests that even with the best error correction in the graph, it is impossible to factor RSA-4 with less then 10^4 qubits. Which seems very odd.

It's because the plot is assuming the use of error correction even for the smallest cases. Error correction has minimum quantity and quality bars that you must clear in order for it to work at all, and most of the cost of breaking RSA4 is just clearing those bars. (You happen to be able to do RSA4 without error correction, as was done in 2001 [0], but it's kind of irrelevant because you need error correction to scale so results without it are on the wrong trendline. That's even more true for the annealing stuff Scott mentioned, which has absolutely no chance of scaling.)

You say you don't see the uranium piling up. Okay. Consider the historically reported lifetimes of classical bits stored using repetition codes on the UCSB->Google machines [1]. In 2014 the stored bit lived less than a second. In 2015 it lived less than a second. 2016? Less than a second. 2017? 2018? 2019? 2020? 2021? 2022? Yeah, less than a second. And this may not surprise you but yes, in 2023, it also lived less than a second. Then, in 2024... kaboom! It's living for hours [4].

You don't see the decreasing gate error rates [2]? The increasing capabilities [3]? The ever larger error correcting code demonstrations [4]? The front-loaded costs and exponential returns inherent to fault tolerance? TFA is absolutely correct: the time to start transitioning to PQC is now.

[0]: https://www.nature.com/articles/414883a

[1]: https://algassert.com/assets/2025-12-24-qec-foom/plot-half-l... (from https://algassert.com/post/2503 )

[2]: https://arxiv.org/abs/2510.17286

[3]: https://www.nature.com/articles/s41586-025-09596-6

[4]: https://www.nature.com/articles/s41586-024-08449-y

Re: A cryptography engineer's perspective on quantum computing timelines

#133

Post by codethief »

rcxdude wrote: post #125
codethief wrote: post #79

> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon. Slightly off-topic but: Does anyone know what the Signal developers plan on doing there to replace SGX? I m…

I'm not sure who particularly cares about the stuff Signal is doing with SGX anyway. It always struck me as a 'because we can' move and if you're paranoid enough to worry about it then you're probably paranoid enough to not trust any manufacturer-based attestation anyway (All SGX does is make Intel the root of trust, and it's not like Signal would be less secure than any other third party if SGX were broken).

> I'm not sure who particularly cares about the stuff Signal is doing with SGX anyway.

Security researchers like Matthew Green seem to care[0], the Signal people surely do, I myself do, too. Isn't that enough to raise that question?

> if you're paranoid enough to worry about it

You make it seem like that's an outlandish thought, when in reality there have been tons of reported vulnerabilities for SGX. And now QC represents another risk.

> it's not like Signal would be less secure than any other third party if SGX were broken

That's a weird benchmark. Shouldn't Signal rather be measured by whether it lives up to the security promises it makes? Signal's whole value proposition is that it's more secure than "third parties".

[0]: https://blog.cryptographyengineering.com/category/signal/

Re: A cryptography engineer's perspective on quantum computing timelines

#134

Post by BitsAndObjects »

BitsAndObjects wrote: post #132

The OP should take a look at Secqai - potentially serverclass motherboard management processors and beyond which will implement PQ security and hardware enforced memory safety (from what I recall): https://www.secqai.com/

This is in response to the comments in the article about TEEs and similar - such as TPMs - not catching up fast enough.

Also companies like PQShield.

The hardware (IP) exists to solve this in time, and is being integrated into products gradually.

No idea how widespread it will become or over what timescale.

Re: A cryptography engineer's perspective on quantum computing timelines

#135

Post by RyujiYasukochi »

amluto wrote: post #111
hujun wrote: post #84

Earlier quoted context omitted.

> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon. compare to SGX, a more critical impacted component is TPM chip, secured/measured boot depends on TPM, and c…

A lot of TPMs are “fTPM”s, which are implemented in something resembling software. It’s an open question whether the hardware in question has usable roots of trust, but a lot of TPM applications don’t actually require endorsement. And some servers have plug-in TPMs. Of course, many critical components on a motherboard and CPU verify their firmware using non-post-quantum keys, which is another issue.

[dead]

Re: A cryptography engineer's perspective on quantum computing timelines

#136

Post by wuiheerfoj »

I buy the argument 'we should prepare for Q-Day as crypto agility is hard', but the newest paper doesn’t change the timeline meaningfully.

Given TFA accepts that error correction is the bottleneck for progress, and the gap between any and lots of error correction is small, and we presently have close to 0 error correction then nothing has practically changed with reduced qubit requirements.

Of course, it’s totally fine to have and announce a change of view on the topic, though I don’t see how the Google paper materially requires it.

Re: A cryptography engineer's perspective on quantum computing timelines

#137

Post by cyberax »

FiloSottile wrote: post #73
phicoh wrote: post #71

Earlier quoted context omitted.

It is the paradox of PQC: from a classical security point of view PQC cannot be trusted (except for hash-based algorithms which are not very practical). So to get something we can trust we need hybrid. However, the premise for introducing PQC in the first place is that quantum computers can break classical public key crypto, so hybrid doesn't provide any benefit over pure PQC. Yes, the sensible thing to do is hybrid.…

> from a classical security point of view PQC cannot be trusted [citation needed] https://words.filippo.io/crqc-timeline/#fn:lattices

It's purely a matter of _potential_ issues. The research on lattice-based crypto is still young compared to EC/RSA. Side channels, hardware bugs, unexpected research breakthroughs all can happen.

And there are no downsides to adding regular classical encryption. The resulting secret will be at least as secure as the _most_ secure algorithm.

The overhead of additional signatures and keys is also not that large compared to regular ML-KEM secrets.

Re: A cryptography engineer's perspective on quantum computing timelines

#138

Post by lucb1e »

tptacek wrote: post #86
lucb1e wrote: post #81

Earlier quoted context omitted.

So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly…

Because you cannot "just literally replace those 3 characters and be done with the upgrade".

That would depend...

There's a whole lot of cases where the tokens are temporary in nature with an easy cut-over, either dropping old entries or re-encrypting while people are not at work. We tend to think of big commerce like amazon or google that need 24/7 uptime, but most individual systems are not of that scale

In most other cases you increment the version number for the new data format and copy-paste the (d)e(n)cryption code for each branch of the if statement, substituting 128 for 256. That's still a trivial change to substitute one algorithm for another

Only if there exists no upgrade path in the first place, you have a big problem upgrading the rest of your cryptography anyway and here it's worth evaluating per-case whether the situation is considered vulnerable before doing a backwards-incompatible change. Just like how people are (still) dealing with md5

Re: A cryptography engineer's perspective on quantum computing timelines

#139

Post by cassonmars »

FiloSottile wrote: post #104
btdmaster wrote: post #102

> “Doesn’t the NSA lie to break our encryption?” No, the NSA has never intentionally jeopardized US national security with a non-NOBUS backdoor, and there is no way for ML-KEM and ML-DSA to hide a NOBUS backdoor. The most concrete issue for me, as highlighted by djb, is that when the NSA insists against hybrids, vendors like telecommunications companies will handwrite poor implementations of ML-KEM to save memory/CPU…

Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argu…

I genuinely do not understand how someone working in the capacity that you do, for things that matter universally for people, can contend that an organization who is intentionally engaging in NOBUS backdoors can be remotely trusted at all.

That is insanely irresponsible and genuinely concerning. I don't care if they have a magical ring that defies all laws of physics and assuredly prevents any adversary stealing the backdoor. If an organization is implementing _ANY_ backdoor, they are an adversary from a security perspective and their guidance should be treated as such.

Re: A cryptography engineer's perspective on quantum computing timelines

#140

Post by cyberax »

phicoh wrote: post #50
FiloSottile wrote: post #41

Earlier quoted context omitted.

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-toleran…

The thing is, producing the right isotopes of uranium is mostly a linear process. It goes faster as you scale up of course, but each day a reactor produces a given amount. If you double the number of reactors you produce twice as much, etc. There is no such equivalent for qubits or error correction. You can't say, we produce this much extra error correction per day so we will hit the target then and then. There is al…

So today you have 1 gram. No bomb. Tomorrow you have 2 grams. Still no bomb.

...

365 days later, you have 365 grams after spending ungodly amounts of energy to separate isotopes. AND STILL NO BOMB! Not even a small one. These scientists are just some bullshit artists.

52kg later: BOOM!

Post reply on HN