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

71–80 of 260 posts

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

#71

Post by phicoh »

adgjlsfhk1 wrote: post #60
scythmic_waves wrote: post #53

Earlier quoted context omitted.

Is it? Your reasoning relies on this being true: > [CRQCs] will be slow, expensive, and power hungry for at least a decade How could you know that? What if it was 5 years? 1 year? 6 months? I predict there will be an insane global pivot once Q-day arrives. No nation wants to invest billions in science fiction. Every nation wants to invest billions in a practical reality of being able to read everyone's secrets.

The absolute low end of cost of a QC is the cost of an MRI machine ~100k-400k (cost of cooling the computer to super low temps). Sure we expect QCs to get faster and cheaper over time, but putting 100% faith in the security of the PQC algorithms seems like a bad idea with no upside.

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. But that does assume that either PQC cannot be broken by classical computers or that quantum computers will be rare or expensive enough that they don't break your classical public key crypto.

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

#72

Post by btilly »

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…

Planning now on a fast upgrade later, is planning on discovering all of the critical bugs after it is too late to do much about them.

Things need to be rolled out in advance of need, so that you can get a do-again in case there proves to be a need.

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

#73

Post by FiloSottile »

phicoh wrote: post #71
adgjlsfhk1 wrote: post #60

Earlier quoted context omitted.

The absolute low end of cost of a QC is the cost of an MRI machine ~100k-400k (cost of cooling the computer to super low temps). Sure we expect QCs to get faster and cheaper over time, but putting 100% faith in the security of the PQC algorithms seems like a bad idea with no upside.

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

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

#74

Post by FiloSottile »

adgjlsfhk1 wrote: post #52
FiloSottile wrote: post #40

Earlier quoted context omitted.

Remember that the entities most likely to heed those governments recommendations are those providing services to said government and its military. I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely. See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for whether…

IMO the idea that NSA only uses NOBUS backdoors is obviously false (see for example DES's 56 bit key size). The NSA is perfectly capable of publicly calling for an insecure algorithm and then having secret documentation to not use it for anything important.

DES is the algorithms that was secretly modified by the NSA to protect it against differential cryptanalysis. Capping a key size is hardly a "backdoor."

Also, that was the time of export ciphers and Suite A vs Suite B, which were very explicit about there being different algorithms for US NatSec vs. everything else. This time there's only CNSA 2.0, which is pure ML-KEM and ML-DSA.

So no, there is no history of the NSA pushing non-NOBUS backdoors into NatSec algorithms.

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

#75

Post by PretzelPirate »

sunshine-o wrote: post #49
Animats wrote: post #36

We'll know it's been cracked when all the lost Bitcoins start to move.

Yep, I was looking into it and from what I understand: - There is a dark outlook on Bitcoin as the community and devs can't seem to coordinate. Especially on what to do with the "Satoshi coins" - Ethereum has a hard but clear path (pretty much full rewrite) with a roadmap [0] - The highly optimized "fast chains" (Solana & co) are in a lot of trouble too. It would be funny if Bitcoin the asset end up migrating to Ethe…

> pretty much full rewrite

This is far from my understanding. Changing out this signature scheme is hard work, but doesn't require a rewrite of the VM.

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

#77

Post by elevation »

amluto wrote: post #26
palata wrote: post #23

What is the consequence on e.g. Yubikeys (or say the Android Keystore)? Do I understand correctly that those count as "signature algorithms" and are a little less at risk than "full TEEs" because there is no "store now, decrypt later" for authentication? E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ encryption, such that I am safe from "store now, decrypt later", but can still use my Yubikey (or And…

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.

Looking forward to a PQ yubikey rev. I would buy a box of them today so I could start experimenting!

Another challenge of the transition is how much silicon we have yet to even implement. Smart cards? Mobile acceleration/offloading? We're at the mercy of vendors.

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

#78

Post by upofadown »

So this is the exciting paper:

* https://arxiv.org/pdf/2603.28627

The new thing here seems to be the use of the neutral atom technique. Supposedly we are up to 96 entangled qubits for a second or two based on neutral atoms.

Shouldn't that be enough capability to factor 15 using Shor's?

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

#79

Post by codethief »

> 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 mean it's not like outside observers haven't been looking very critically at SGX usage in Signal for years (which the Signal devs have ignored), but this does seem to put additional pressure on them.

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

#80

Post by tptacek »

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…

Signal uses SGX for features every other mainstream E2E messenger does in serverside plaintext.
Post reply on HN