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

101–110 of 260 posts

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

#101

Post by tptacek »

octoberfranklin wrote: post #94
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…

> produce at least a small nuclear explosion The Manhattan Project scientists actually did this before anybody broke ground at Los Alamos. It was called the Chicago Pile. And if the control rods were removed and the SCRAM disabled, it absolutely would have created a "small nuclear explosion" in the middle of a major university campus. Given the level of hype and how long it's been going on, I think it's totally reaso…

What? No. No matter what anybody did with the Chicago Pile, it would never have produced a small version of a nuclear detonation.

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

#102

Post by btdmaster »

> “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 time etc. for their constrained hardware that will have stacks of timing side channels for the NSA to break. Meanwhile X25519 has standard implementations that don't have such issues already deployed, which the NSA presumably cannot break (without spending $millions per key with a hypothetical quantum attack, a lot more expensive than side channels).

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

#103

Post by Avamander »

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…

> The most concrete issue for me, as highlighted by djb, is that when the NSA insists against hybrids

The fact that only NSA does that and they really have no convincing arguments seems like the biggest reason why the wider internet should only roll out hybrids. Then possibly wait decades for everything to mature and then reconsider plain modes of operation.

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

#104

Post by FiloSottile »

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 argument against the NSA promoting mathematically broken cryptography, if anything.)

Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's really hard to implement ML-KEM wrong. It's way easier to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise.

(I also think these days P-256 is fine, but that is a different argument.)

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

#105

Post by snowwrestler »

adrian_b wrote: post #21
FiloSottile wrote: post #18

Earlier quoted context omitted.

That was my position until last year, and pretty much a consensus in the industry. What changed is that the new timeline might be so tight that (accounting for specification, rollout, and rotation time) the time to switch authentication has also come. ML-KEM deployment is tangentially touched on in the article because it's both uncontroversial and underway, but: > This is not the article I wanted to write. I’ve had a…

I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. However that does not mean that the switch should really be done as soon as it is possible, because it would add unnecessary overhead. This could be done by distributing a set of post-quantum certificates, while continuing to allow the use of the existing cert…

> I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately.

Personally, my reading between the lines on this subject as a non-expert is that we in the public might not know when post-quantum cryptography is necessary until quite a while after it is necessary.

Prior to the public-key cryptography revolution, the state of the art in cryptography was locked inside state agencies. Since then, public cryptographic research has been ahead or even with state work. One obvious tell was all the attempts to force privately-operated cryptographic schemes to open doors to the government via e.g. the Clipper chip and other appeals to magical key escrow.

A whole generation of cryptographers grew up in this world. Quantum cryptography might change things back. We know what papers say from Google and other companies. Who knows what is happening inside the NSA or military facilities?

It seems that with quantum cryptography we are back to physics, and the government does secret physics projects really well. This paragraph really stood out to me:

> Scott Aaronson tells us that the “clearest warning that [he] can offer in public right now about the urgency of migrating to post-quantum cryptosystems” is a vague parallel with how nuclear fission research stopped happening in public between 1939 and 1940.

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

#106

Post by fireflash38 »

ekr____ wrote: post #43
FiloSottile wrote: post #38

Earlier quoted context omitted.

Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time…

> In both cases, you need to start moving now and gain little from trying to time the switchover. There are a number of "you"s here, including: - The SDOs specifying the algorithms (IETF mostly) - CABF adding the algorithms to the Baseline Requirements so they can be used in the WebPKI - The HSM vendors adding support for the algorithms - CAs adding PQ roots - Browsers accepting them - Sites deploying them This is a…

If your HSM vendor isn't actively working on/have a release date for GA PQ, you should probably get a new vendor.

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

#107

Post by FiloSottile »

palata wrote: post #99
FiloSottile wrote: post #93

Earlier quoted context omitted.

If you are doing authentication with those hardware keys, you will probably be fine, if we do our job fast enough. Apple's Secure Enclave already supports some PQ signatures (although annoyingly not ML-DSA-44 apparently?) and I trust Yubico is working on it. If you are doing encryption, then you do have reason to worry, and there aren't great options right now. For example if you are using age you should switch to hy…

Thanks a lot, that helps! > This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS and have a CRQC. Did you mean "your OS and have a CRQC" here, or "your Yubikey and have a CRQC"?

I mean "your OS and have a CRQC" because they will need to compromise the software PQ key by compromising the OS, and derive the hardware YubiKey private key using the CRQC.

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

#108

Post by ameliaquining »

ls612 wrote: post #82
amluto wrote: post #26

Earlier quoted context omitted.

Your Yubikey itself is doomed. If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Well, as long as the PQ key exchange holds up, and I am personally not as optimistic about that as I’d like to be.

Is this also true for other TPM/snitching/DRM chips out there? IE will every existing device eventually become jailbreakable in the future or will we unfortunately not even get that benefit from all this?

The timeline here is for when major governments have access to CRQCs. It will be much longer than that (barring an AI singularity or something) before you have access to one.

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

#109

Post by raron »

snowwrestler wrote: post #105
adrian_b wrote: post #21

Earlier quoted context omitted.

I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. However that does not mean that the switch should really be done as soon as it is possible, because it would add unnecessary overhead. This could be done by distributing a set of post-quantum certificates, while continuing to allow the use of the existing cert…

> I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. Personally, my reading between the lines on this subject as a non-expert is that we in the public might not know when post-quantum cryptography is necessary until quite a while after it is necessary. Prior to the public-key cryptography revolution, the state…

> Since then, public cryptographic research has been ahead or even with state work.

How can we know that?

> Who knows what is happening inside the NSA or military facilities?

Couldn't have NSA found an issue with ML-KEM and try to convince people to use it exclusively (not in hybrid scheme with ECC)?

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

#110

Post by palata »

FiloSottile wrote: post #107
palata wrote: post #99

Earlier quoted context omitted.

Thanks a lot, that helps! > This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS and have a CRQC. Did you mean "your OS and have a CRQC" here, or "your Yubikey and have a CRQC"?

I mean "your OS and have a CRQC" because they will need to compromise the software PQ key by compromising the OS, and derive the hardware YubiKey private key using the CRQC.

Oh right, I got it now!
Post reply on HN