A cryptography engineer's perspective on quantum computing timelines • Hacker News Board

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

#251

Post by bwesterb » Wed, Apr 08, 2026, 11:53 AM UTC

vlovich123 wrote: post #227

bwesterb wrote: post #208

Earlier quoted context omitted.

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.…

For me presuming Q-day will happen which is why I categorize that more as a maximalist camp, same as people who believe AGI is inevitable are AI maximalists. I could also be misremembering our conversation, but I thought you had said something like 2029 or 2030 in our 2020 conversation :)? My concern is that there's so much human and financial capital behind quantum computing that the "experts" have lots of reason to…

> 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.

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

#252

Post by xorcist » Wed, Apr 08, 2026, 12:02 PM UTC

bhaak wrote: post #130

> They weirdly[1] frame it around cryptocurrencies and mempools and salvaged goods or something [...] > [1] The whole paper is a bit goofy: it has a zero-knowledge proof for a quantum circuit that will certainly be rederived and improved upon before the actual hardware to run it on will exist. They seem to believe this is about responsible disclosure, so I assume this is just physicists not being experts in our field…

> Bitcoin, where users would need to migrate their coins to a quantum-resistant scheme

Is that so? I always thought that the design choice that only hashes of the public keys were public was a pretty clever way to make the whole scheme quantum-proof. What did I miss?

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

#253

Post by tptacek » Wed, Apr 08, 2026, 1:09 PM UTC

Perseids wrote: post #250

tptacek wrote: post #247

Earlier quoted context omitted.

This is like saying we should have halted all RSA deployments until improvements in sieving stopped happening. The lattice contestants were all designed assuming BKZ would continually improve. It's not 1994 anymore, asymmetric cryptography is not a huge novelty to the industry, nobody is doing the equivalent of RSA-512.

> This is like saying we should have halted all RSA deployments until improvements in sieving stopped happening. Absolutely not. If people were advocating for ECC only, you would have a point. But this thread is about hybrids vs ML-KEM-only (for key exchange!). Everybody here wants to deploy the algorithm your favoring and wants to deploy it now, just not without a safety net.

I don't understand. We didn't have hybrids for RSA while sieving improved.

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

#254

Post by adgjlsfhk1 » Wed, Apr 08, 2026, 1:48 PM UTC

tptacek wrote: post #253

Perseids wrote: post #250

Earlier quoted context omitted.

> This is like saying we should have halted all RSA deployments until improvements in sieving stopped happening. Absolutely not. If people were advocating for ECC only, you would have a point. But this thread is about hybrids vs ML-KEM-only (for key exchange!). Everybody here wants to deploy the algorithm your favoring and wants to deploy it now, just not without a safety net.

I don't understand. We didn't have hybrids for RSA while sieving improved.

RSA was the first. If ECC didn't exit, no one would be saying that we have to hybridize Kyber, but since it does, and the hybrid has ~0% overhead, it's very silly not to.

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

#255

Post by adgjlsfhk1 » Wed, Apr 08, 2026, 4:59 PM UTC

fc417fc802 wrote: post #249

adgjlsfhk1 wrote: post #246

Earlier quoted context omitted.

The requirement for favoring hybrid isn't that "you view classically breaking PQ algorithms as higher likelihood than QC breaking classical", but you think that the likelihood than QC breaking classical is less than a billion times more than the likelyhood of classically breaking PQ. Hybrid has essentially no cost, so we should favor it as long as it has a greater than negligible chance of providing protection. IMO t…

Not so. One of the core premises of the article that we're discussing here is that hybrid is proving to be quite difficult for entirely nontechnical reasons. I agree that my previous wording was sloppy to the point of error. The point I was trying to communicate was that we already had agreement that an elevated assessment of the chance of a classical attack against a given PQ algorithm would lead to one disagreeing…

> hybrid is proving to be quite difficult for entirely nontechnical reasons.

This is hard to square with the reality that hybrid systems are already widely deployed while pure PQC aren't/

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

#256

Post by fc417fc802 » Wed, Apr 08, 2026, 10:16 PM UTC

adgjlsfhk1 wrote: post #255

fc417fc802 wrote: post #249

Earlier quoted context omitted.

Not so. One of the core premises of the article that we're discussing here is that hybrid is proving to be quite difficult for entirely nontechnical reasons. I agree that my previous wording was sloppy to the point of error. The point I was trying to communicate was that we already had agreement that an elevated assessment of the chance of a classical attack against a given PQ algorithm would lead to one disagreeing…

> hybrid is proving to be quite difficult for entirely nontechnical reasons. This is hard to square with the reality that hybrid systems are already widely deployed while pure PQC aren't/

[dead]

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

#257

Post by nullc » Thu, Apr 09, 2026, 1:22 AM UTC

nullc wrote: post #85

sunshine-o wrote: post #49

Earlier quoted context omitted.

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…

Adding new signature schemes to bitcoin is relatively trivial and has been done previously (today Bitcoin supports both schnorr and ecdsa signatures). Existing PQ standards have signatures with the wrong efficiency tradeoffs for usage in Bitcoin-- large signatures that are durable against a lot of use and supports fast signing, while for Bitcoin signature+key size is critical, keys should be close to single use, and…

Replying to a dead reply:

> A scam creates the credulous, not the skeptical. To portray skeptics as byproducts of a scam is an insult to logic — and a classic straw man fallacy.

No. When the scam is successful against a target the target is in on it and all for it and hands over their money. When the scam fails there are a number of different outcomes and one of them is thinking "this is real, going to happen, very scary, and also absolutely illegal, immoral, and/or self defeating, so I want no part of it".

Inherently scams tend to only convert a small percentage of their prospects,-- ones that don't aren't ambitious enough (e.g. aren't asking for enough money) and risk running their path too quickly by signing on too many people and getting too much exposure too fast.

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

#258

Post by TomatoCo » Thu, Apr 09, 2026, 2:01 AM UTC

FiloSottile wrote: post #25

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…

How do you do revocation or software updates securely if your current signature algorithm is compromised?

You can't do software updates securely, but it strikes me that compromising the revocation process is a good thing. Suppose you can use a key to sign a message saying "stop using this". If someone else breaks that key and falsely signs that message, what are the downsides?

You revoke a cert because you lose control of it; if someone else can falsely revoke that cert, doesn't that truthfully send the exact same signal? That you lose control of it?

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

#259

Post by xorcist » Thu, Apr 09, 2026, 8:29 AM UTC

some_furry wrote: post #220

xorcist wrote: post #218

Earlier quoted context omitted.

The actual revocation needn't be secure. False revocations are an oxymoron. The practice around revocations need to be secure of course, but that's more on an engineering problem than a cryptographical.

Can you explain a bit more what you mean by "secure" in the context of "actual revocations"? The oxymoronic nature isn't self-evident enough for me to catch your intended meaning before my first cup of coffee.

How can you falsely revoke a certificate? If an attacker can revoke a certificate, either by falsifying the signature or possessing the necessary key material, it is by definition not a trustworthy certificate anymore, and the revocation is therefore correct.

In the public CA PKI, it is the CA which has the power to revoke their issued certificates. In other systems, it can be the private key for the certificate itself. In either case, the certificate is not to be trusted anymore.

Revocation is the least of your worries should your signature algorithm be broken in the future.

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

#260

Post by some_furry » Thu, Apr 09, 2026, 2:47 PM UTC

xorcist wrote: post #259

some_furry wrote: post #220

Earlier quoted context omitted.

Can you explain a bit more what you mean by "secure" in the context of "actual revocations"? The oxymoronic nature isn't self-evident enough for me to catch your intended meaning before my first cup of coffee.

How can you falsely revoke a certificate? If an attacker can revoke a certificate, either by falsifying the signature or possessing the necessary key material, it is by definition not a trustworthy certificate anymore, and the revocation is therefore correct. In the public CA PKI, it is the CA which has the power to revoke their issued certificates. In other systems, it can be the private key for the certificate itse…

> How can you falsely revoke a certificate?

If you don't have the private key on hand to issue a revocation, your next best bet is to find a parser bug that convinces some subset of user agents that the valid certificate you don't hold the private key for is actually invalid. (Hence, a false revocation.)

And then, get those users into the habit of accepting invalid/revoked certificates if they want to access the site. And then after weeks of battling against their patience or endurance, then you offer an invalid cert for a MitM.

That's how I was thinking of it, anyway.