alt.hn

4/6/2026 at 3:31:20 PM

A cryptography engineer's perspective on quantum computing timelines

 https://words.filippo.io/crqc-timeline/

by thadt

4/6/2026 at 5:47:52 PM

It should be noted that if indeed there has not remained much time until a usable quantum computer will become available, the priority is the deployment of FIPS 203 (ML-KEM) for the establishment of the secret session keys that are used in protocols like TLS or SSH.

ML-KEM is intended to replace the traditional and the elliptic-curve variant of the Diffie-Hellman algorithm for creating a shared secret value.

When FIPS 203, i.e. ML-KEM is not used, adversaries may record data transferred over the Internet and they might become able to decrypt the data after some years.

On the other hand, there is much less urgency to replace the certificates and the digital signature methods that are used today, because in most cases it would not matter if someone would become able to forge them in the future, because they cannot go in the past to use that for authentication.

The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them.

OpenSSH, OpenSSL and many other cryptographic libraries and applications already support FIPS 203 (ML-KEM), so it could be easily deployed, at least for private servers and clients, without also replacing the existing methods used for authentication, e.g. certificates, where using post-quantum signing methods would add a lot of overhead, due to much bigger certificates.

by adrian_b

4/6/2026 at 5:55:54 PM

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 pending draft for months now explaining we should ship PQ key exchange now, but take the time we still have to adapt protocols to larger signatures, because they were all designed with the assumption that signatures are cheap. That other article is now wrong, alas: we don’t have the time if we need to be finished by 2029 instead of 2035.

> For key exchange, the migration to ML-KEM is going well enough but: 1. Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because it’s very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years. [...]

You comment is essentially the premise of the other article.

by FiloSottile

4/6/2026 at 6:04:42 PM

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 certificates. When necessary, the classic certificates could be revoked immediately.

by adrian_b

4/6/2026 at 9:58:16 PM

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

by snowwrestler

4/6/2026 at 10:25:22 PM

> 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)?

by raron

4/6/2026 at 11:41:13 PM

Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm?

What's the PQC construction you couldn't say either thing about?

by tptacek

4/7/2026 at 11:00:11 AM

> Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm?

Could, but they did not do that. So, the question is to be stated: Why?

by deknos

4/7/2026 at 2:37:13 PM

I think you may have missed my point.

by tptacek

4/6/2026 at 10:48:19 PM

Follow nsa suite-b and what the USA forces on different levels of classification.

by goalieca

4/7/2026 at 1:54:40 PM

Kyber/ML-KEM-only is exactly the suite b (CNSA 2) recommendation.

by formerly_proven

4/6/2026 at 7:32:59 PM

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.

by btilly

4/6/2026 at 6:14:13 PM

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

by FiloSottile

4/6/2026 at 6:24:14 PM

As a practical matter, revocation on the Web is handled mostly by centrally distributed revocation lists (CRLsets, CRLite, etc. [0]), so all you really need is:

(1) A PQ-secure way of getting the CRLs to the browser vendors. (2) a PQ-secure update channel.

Neither of these require broad scale deployment.

However, the more serious problem is that if you have a setting where most servers do not have PQ certificates, then disabling the non-PQ certificates means that lots of servers can't do secure connections at all. This obviously causes a lot of breakage and, depending on the actual vulnerability of the non-PQ algorithms, might not be good for security either, especially if people fall back to insecure HTTP.

See: https://educatedguesswork.org/posts/pq-emergency/ and https://www.chromium.org/Home/chromium-security/post-quantum...

[0] The situation is worse for Apple.

by ekr____

4/6/2026 at 6:38:39 PM

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

by FiloSottile

4/6/2026 at 6:46:35 PM

> 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 very long supply line and the earlier players do indeed need to make progress. I'm less sure how helpful it is for individual sites to add PQ certificates right now. As long as clients will still accept non-PQ algorithms for those sites, there isn't much security benefit so most of what you are doing is getting some experience for when you really need it. There are obvious performance reasons not to actually have most of your handshakes use PQ certificates until you really have to.

by ekr____

4/6/2026 at 6:56:48 PM

Yeah, that's an audience mismatch, this article is for "us." End users of cryptography, including website operators and passkey users (https://news.ycombinator.com/item?id=47664744) can't do much right now, because "we" still need to finish our side.

by FiloSottile

4/6/2026 at 10:03:17 PM

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

by fireflash38

4/7/2026 at 7:10:12 AM

I do not understand the fixation on authentication/signatures. They have different threat characteristics:

You cannot retroactively forge historical authentication sessions, and future forgery ability does not compromise past data, and it only matters for long-lived signed artifacts (certificates, legal documents, etc.), yet the thread apparently keeps pivoting to signature deployment complexity?

I do not get it.

by johnisgood

4/7/2026 at 7:58:21 AM

The argument is that deploying PQ-authentication mechanisms takes time. If the authenticity of some connections (firmware signatures, etc…) is critical to you and news comes out that (")cheap(") quantum attacks are going to materialize in six months, but you need at least twelve months to migrate, you are screwed.

There is also a difference between closed ecosystems and systems that are composed of components by many different vendors and suppliers. If you are Google, securing the connection between data centers on different continents requires only trivial coordination. If you are an industrial IoT operator, you require dozens of suppliers to flock around a shared solution. And for comparison, in the space of operation technology ("OT"), there are still operators that choose RSA for new setups, because that is what they know best. Change happens in a glacial pace there.

by Perseids

4/7/2026 at 1:40:49 PM

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.

by xorcist

4/7/2026 at 1:49:41 PM

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.

by some_furry

4/7/2026 at 4:38:35 PM

If you receive a forged crl, in the worst case it will revoke certificates that you can't trust anyway. Even if it says "certificate X is still good", that's equivalent to receiving no crl.

by GoblinSlayer

4/7/2026 at 11:00:57 AM

Use PSK signature.

by GoblinSlayer

4/7/2026 at 6:00:03 AM

> when it becomes necessary

Perhaps it's already necessary, or it will be in the following months. We are hearing only about the public developments, not whatever classified work the US is doing

I think the analogy with the Manhattan project is apt. The US has enormous interest in decrypting communication streams at scale (see Snowden and the Utah NSA datacenter), and it's known for storing encrypted comms for decrypting later. Well maybe later is now

by nextaccountic

4/7/2026 at 7:32:31 AM

Super important: Don't replace traditional (elliptic curve) Diffie-Hellman with ML-KEM, but enhance it by using hybrid key exchanges. Done thusly, you need to break both the classical and post-quantum cryptography to launch an attack.

If you worry about a >=1% risk of quantum attacks being available soon, you should also worry about a >=1% risk of the relatively new ML-KEM being broken soon. The risk profile is pretty comparable. For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated.

Filippo has linked opinions that quantum attacks are right around the corner. People like Dan Bernstein (djb) are throwing all their weight to stress that anything but hybrids are irresponsible. I don't think there is anybody that says "hybrids are a bad idea", just people that want to make it easy to choose non-hybrid ML-KEM.

by Perseids

4/7/2026 at 11:25:39 AM

How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean you have to repeat it uncritically.

by pie_flavor

4/7/2026 at 1:26:22 PM

> How do you mean the risk profile is comparable

Exactly in the way the succeeding sentence defines: "For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated."

> when ECDH is nearly guaranteed to be broken in five years

Most of your argument (and that of many others pushing the contra-hybrid point) hinges on this. I don't think this position is justified. I believe there is significant risk for quantum attacks in the near term (and thus fully support the speedy adoption of hybrids), yes, but quite far away from certainty. Personally, I'd even say better than coin-flip is pushing it. I mean, look at what Scott Aaronson is writing on that matter:

"I also continue to profess ignorance of exactly how many years it will take to realize those principles in the lab, and of which hardware approach will get there first. […] This year [=2025] updated me in favor of taking more seriously the aggressive pronouncements—the “roadmaps”—of Google, Quantinuum, QuEra, PsiQuantum, and other companies about where they could be in 2028 or 2029." -- https://scottaaronson.blog/?p=9425

This is nothing like "nearly guaranteed" in five years.

> and Kyber is two decades old

But the implementations aren't and it's not been under heavy scrutiny for that long. One can very much make the point that we weren't that critical when elliptic curve cryptography entered the scene, but we do now have the luxury to have these heavily battle-tested primitives and implementations at our disposal, so why throw them out of the window so eagerly? Also an interesting comparison to elliptic curve cryptography is that it took until 2005 to get good key exchanges primitives and until 2011 to get good signature primitives (Curve25519, now known as X25519, and Ed25519 respectively) and mainstream availability of those took waaaay longer.

Coming back to this again, for second remark:

> when ECDH is nearly guaranteed to be broken in five years

Another important point is all quantum attack on ECDH will require inherently expensive equipment for the foreseeable future, see adgjlsfhk1's comment https://news.ycombinator.com/item?id=47665561 , whereas a stupid Kyber implementation error in a mainstream library can very likely end up being attackable by a Metasploit plugin. Our threat model should most definitely include nation state attackers prominently, but these are not at all the only attackers that we should focus on. There is still significant value in keeping out attackers that did not spend >100k$ on equipment.

> Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean you have to repeat it uncritically.

I did not repeat it uncritically, I just happen to share his conclusion, even after months of following the pro and contra discussion. Also, how can you say he complains without reason? He has explained them at length, see https://cr.yp.to/2025/20250812-non-hybrid.pdf for example. Whether his methods of complaining are commendable or effective is another topic, though.

by Perseids

4/7/2026 at 2:39:33 PM

I would be interested in seeing you rattle off the "pros and cons" of this argument, just as a synchronization mechanism for the thread so we'd know if we're on the same page.

by tptacek

4/7/2026 at 4:25:41 PM

Off the top of my head?

Pro hybrid: Negligible performance impact (negligible for battery devices, negligible for data send over the wire (number of packets -> sub-discussion about specific circumstances, time on the air for cellular), negligible for speed, negligible code size increase), little implementation effort as every library already has ECC in it, ML-KEM is too new (yes actually old, but far less research interest, implementations new), conservative design choice

Pro ML-KEM only / produce a TLS RFC for non-hybrid ML-KEM: Reduction in complexity, reduction of transitions (non-hybrid is going to be the final state, so lets skip ahead already), lattice crypto is actually an old branch of cryptography (discussion over different metrics), NSA says its secure for government use, NSA stipulates use of non-hybrid and we want/need to be compatible, we want/need to have a well defined place to have a reference, if people are going to write an RFC to document non-hybrid ML-KEM let us at least have influence over what is written there, better performance (speed, data on the wire, number of packets in handshake, energy budget), actually the non-hybrid TLS connection is intended to be the inner one while the outer transport is secured with classic cryptography (or vice versa) so hybrids are a complete waste, for any interesting timeline ECC is broken anyway so it is a useless burden, we just want choice dammit, don't undermine the process dammit.

Pro hybrid only / don't produce a TLS RFC for non-hybrid ML-KEM: Let's not make it easy for people to choose wrongly by accident/incompetence/malice, actually no complexity reduction as implementations still need to implement hybrids to be compatible, TLS WG publishing something has weight and might sway others to consider non-hybrid ML-KEM, NSA might have pushed for non-hybrid ML-KEM because they believe only they can break it, don't care if US institutions are pushing for non-hybrid ML-KEM for weird internal political reasons, don't you see how this is all a ploy to weaken our crypto again?, don't undermine the process dammit.

Did I forget any important talking point? The TLS WG discussion is actually quite tiresome. For anybody new the party, here is a random pointer for a current thread: https://mailarchive.ietf.org/arch/msg/tls/7OGS_X1e-zG8O0eRJP...

by Perseids

4/8/2026 at 2:24:17 AM

one more Pro hybrid only: reduction of transitions is doubtful since by the time PQC is clearly better, we're likely to have better PQC algorithms (and or better attacks that force more conservative parameters). At a bare minimum, we aren't ready to move to pure PQC until we can go a couple years without continued improvements in lattice reduction algorithms.

by adgjlsfhk1

4/8/2026 at 4:15:40 AM

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.

by tptacek

4/8/2026 at 7:02:17 AM

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

by Perseids

4/8/2026 at 1:09:48 PM

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

by tptacek

4/8/2026 at 1:48:16 PM

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.

by adgjlsfhk1

4/7/2026 at 1:07:04 PM

> when ECDH is nearly guaranteed to be broken in five years

Says who?

There's a big difference between “we can't be sure that ECDH stays secure for five more years” and “ECDH is nearly guaranteed to be broken”. There has been two major papers in the beginning of the year that advanced the state of the art enough to question the prior assumption about the slowness of QC progress. Now we know that rapid advances are possible and we must take that into account in risk assessment. But that doesn't mean that rapid advances are guaranteed. Things could stay stagnant for 15 more years at this point before the next breakthrough. And if that's the case, then ECDH could very well remain relevant for the remaining century.

We just cannot know if it happens, so we can't take the risk. But that doesn't mean that we are certain that the risk will materialize.

by littlestymaar

4/6/2026 at 6:04:42 PM

> The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them.

This very much exists. In particular, the cryptographic timestamps that are supposed to protect against future tampering are themselves currently using RSA or EC.

by layer8

4/6/2026 at 6:37:28 PM

Yes, though we do know how to solve this problem by using hash-based timestamping systems. See: https://link.springer.com/article/10.1007/BF00196791

Of course, the modern version of this is putting the timestamp and a hash of the signature on the blockchain.

by ekr____

4/6/2026 at 6:40:08 PM

What surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it.

The weird thing we have right now is that quantum computers are absolutely hopeless doing anything with RSA and as far as I know, nobody even tried EC. And that state of the art has not moved much in the last decade.

And then suddenly, in a few years there will be a quantum computer that can break all of the classical public key crypto that we have.

This kind of stuff might happen in a completely new field. But people have been working on quantum computers for quite a while now.

If this is easy enough that in a few years you can have a quantum computer that can break everything then people should be able to build something in a lab that breaks RSA 256. I'd like to see that before jumping to conclusions on how well this works.

by phicoh

4/6/2026 at 6:44:16 PM

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-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

To summarize, the hard part of scalable quantum computation is error correction. Without it, you can't factorize essentially anything. Once you get any practical error correction, the distance between 32-bit RSA and 2048-bit RSA is small. Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part.

This is what the experts know, and why they tell us of the timelines they do. We'd do better not to dismiss them by being smug about our layperson's understanding of their progress curve.

by FiloSottile

4/7/2026 at 4:36:11 AM

I’ve worked with Bas. I respect him, but he is definitely a QC maximalist in a way. At the very least he believes that caution suggests the public err on the side of believing we will build them.

The actual challenge is we still don’t know if we can build QC circuits that factorize faster than classical both because the amount of qubits has gone from ridiculously impossible to probably still impossible AND because we still don’t know how to build circuits that have enough qbits to break classical algorithms larger or faster than classical computers, which if you’re paying attention to the breathless reporting would give you a very skewed perception of where we’re at.

It’s also easy to deride your critics as just being contrarian on forums, but the same complaint happens to distract from the actual lack of real forward progress towards building a QC. We’ve made progress on all kinds of different things except for actually building a QC that can scale to actually solve non trivial problems . It’s the same critique as with fusion energy with the sole difference being that we actually understand how to build a fusion reactor, just not one that’s commercially viable yet, and fusion energy would be far more beneficial than a QC at least today.

There’s also the added challenge that crypto computers only have one real application currently which is as a weapon to break crypto. Other use cases are generally hand waved as “possible” but unclear they actually are (ie you can’t just take any NP problem and make it faster even if you had a compute and even traveling salesman is not known to be faster and even if it is it’s likely still not economical on a QC).

Speaking of experts, Bas is a cryptography expert with a specialty in QC algorithms, not an expert in building QC computers. Scott Aronson is also well respected but he also isn’t building QC machines, he’s a computer scientist who understands the computational theory, but that doesn’t make him better as a prognosticator if the entire field is off on a fool’s errand. It just means he’s better able to parse and explain the actual news coming from the field in context.

by vlovich123

4/7/2026 at 11:34:18 AM

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.

by bwesterb

4/7/2026 at 3:43:57 PM

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 try to convince you that it's going to happen any day now. The cryptographic community is rightly scared by the potential because we don't have any theoretical basis to contradict that QC speedups aren't physically possible, but we also don't have any proof (existence or theoretical) that proves they are actually possible.

The same diagrams that are showing physical q-bits per year or physical qbits necessary to crack some algorithm are the same ones powering funding pitches and that's very dangerous to me - it's very possible it's a tail wagging the dog situation.

The negative evidence here for me is that all the QC supremacy claims to date have constantly evaporated as faster classical algorithms have been developed. This means the score is currently 0/N for a faster than classical QC. The other challenge is we don't know where BQP fits or if it even exists as a distinct class or if we just named a theoretical class of problems that doesn't actually exist as a distinct class. That doesn't get into the practical reality that layering more and more error correction doesn't matter so much when the entire system still decoheres at any number at all relevant for theoretically being able to solve non-trivial problems.

Should we prepare for QC on the cryptography side? I don't know but I'm still less < 10% chance that CRQC happens in the next 20 years. I also look at the other situation - if CRQC doesn't ever happen, we're paying a meaningful cost both in terms of human capital spent hardening systems against it and ongoing in terms of slowing down worldwide communications to protect against a harm that never materializes (not to mention all the funding burned spent chasing building the QC). The problem I'm concerned about is that there's no meaningful funding spent trying to crack whether BQP actually exists and what this complexity class actually looks like.

by vlovich123

4/8/2026 at 11:53:09 AM

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

by bwesterb

4/6/2026 at 7:05:33 PM

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 also something weird in the graph in https://bas.westerbaan.name/notes/2026/04/02/factoring.html. 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. At the same time, Scott Aaronson wrote: "you actually can now factor 6- or 7-digit numbers with a QC". Which in the graph suggests that error rate must be very low already or quantum computers with an insane number of qubits exist.

Something doesn't add up here.

by phicoh

4/6/2026 at 7:22:44 PM

We are stretching the metaphor thin, but surely the progress towards an atomic bomb was not measured only in uranium production, in the same way that the progress towards a QC is not measured only in construction time of the machine.

At the theory level, there were only theories, then a few breakthroughs, then some linear production time, then a big boom.

> Something doesn't add up here.

Please consider it might be your (and my) lack of expertise in the specific sub-field. (I do realize I am saying this on Hacker News.)

by FiloSottile

4/7/2026 at 4:40:22 AM

Not only, but a huge challenge was manufacturing enough fuel and was the real limiting part. They were working out hard science and engineering but more fuel definitely == bigger bomb in a very real way and it is quite linear because E=mc^2. And it was in many ways the bottleneck for the bombs - it literally guided how big they made the first bomb and the US manufactured enough for 3 - 1 test, 2 to drop

by vlovich123

4/7/2026 at 12:25:36 AM

> 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

by Strilanc

4/6/2026 at 7:10:36 PM

You can already factor a 6 digit number with a QC, but not with an algorithm that scales polynomially. The graph linked is for optimized variants of Shor's algorithm.

by adgjlsfhk1

4/7/2026 at 1:07:11 AM

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!

by cyberax

4/7/2026 at 12:57:13 PM

But you know beforehand how much you need. We can measure and make predictions with accuracy.

by aragilar

4/7/2026 at 1:49:12 PM

Not a very good analogy, because by the time you get 26 kg, I still have 71 years before you get the bomb.

by littlestymaar

4/7/2026 at 1:19:52 PM

> Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part.

I don't like this analogy very much, because in practice making a nuclear reaction is much, much easier than making a nuclear bomb. You don't need any kind of enrichment or anything, just a big enough pile of natural uranium and graphite [1].

Making a bomb on the other hand, required an insane amount of engineering: from doing isotope separation to enrich U235 to an absurd level (and / or, extract plutonium from the wastes of a nuclear reactor) to designing a way to concentrate a beyond critical mass of fissile element.

The Manhattan project isn't famous without reason, it was an unprecedented concerted effort that wouldn't have happened remotely as quickly in peacetime.

[1]: https://en.wikipedia.org/wiki/Chicago_Pile-1

by littlestymaar

4/6/2026 at 9:21:59 PM

> 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 reasonable for the wider world to ask the quantum crypto-breaking people to build a Chicago Pile first.

https://en.wikipedia.org/wiki/Chicago_Pile-1

by octoberfranklin

4/6/2026 at 11:28:25 PM

A meltdown is not a nuclear explosion. It's not even what happens if you fail to make a nuke go off properly.

by rcxdude

4/7/2026 at 2:25:17 AM

In truth the Chicago Pile crowd were all about power generation and didn't think it was feasible to make a nuclear bomb ..

( Not impossible, more strictly "beyond reach" economically and processing wise, operating on over estimates of the effort and approach )

They ignored letters from Albet Einstein on the topic, they ignored or otherwise disregarded several letters from the Canadian / British MAUD Committee / Tube Alloys group and it took a personal visit from an Australian for them to sit up and take note that such a thing was actually within reach .. although it'd take some man power and a few challenges along the way.

* https://en.wikipedia.org/wiki/MAUD_Committee is one place to start on all that.

by defrost

4/6/2026 at 9:34:15 PM

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

by tptacek

4/7/2026 at 2:27:43 AM

> And that state of the art has not moved much in the last decade

This is far from true. On the experimental side, gate fidelities and physical qubit numbers have increased significantly (a couple of orders of magnitude). On the theory side, error correction techniques have improved astronomically -- overhead to of error corrections has dropped by many orders of magnitude. On the error correction side progress has been feverish over the last 4 years in particular.

by krastanov

4/6/2026 at 6:45:59 PM

IIRC the largest number factored still remains 21

by thhoo5886gjggy

4/7/2026 at 5:40:40 AM

Yeah that's treating D-Wave "breaking" RSA-2048 as the fraud that it is. They didn't factor anything, they computed a square root.

I'm still dubious about the accelerated timeline given what quite a bit of what is presented as progress in the field is fraud or borderline fraud when inspected closely. (e.g. some of the recent majorana claims by Microsoft are at best overhyped, at worst fraud)

by brohee

4/6/2026 at 6:54:14 PM

His article specifically mentions that the threat is with the public key exchange, not the encryption that happens after the key exchange.

by venusenvy47

4/7/2026 at 12:27:58 PM

[dead]

by driftcoder

4/6/2026 at 5:02:58 PM

This is a good take, there's really not much to argue about.

>[...] the availability of HPKE hybrid recipients, which blocked on the CFRG, which took almost two years to select a stable label string for X-Wing (January 2024) with ML-KEM (August 2024), despite making precisely no changes to the designs. The IETF should have an internal post-mortem on this, but I doubt we’ll see one

My kingdom for a standards body that discusses and resolves process issues.

by tux3

4/6/2026 at 6:46:51 PM

I think the anti-hybrid argument the article makes is clearly wrong. Even if CRQCs existed today, we still should be using hybrid algorithms because even once CRQCs exist, they will be slow, expensive, and power hungry for at least a decade. The hybrid algorithms at a minimum make the cost of any attack ~$1M, which is way better than half of the PQC algorithms that made it to the 3rd stage of the PQC competition (2 of them can be broken on a laptop)

by adgjlsfhk1

4/6/2026 at 7:07:24 PM

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.

by scythmic_waves

4/6/2026 at 7:18:39 PM

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.

by adgjlsfhk1

4/6/2026 at 7:30:21 PM

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.

by phicoh

4/6/2026 at 7:36:13 PM

> from a classical security point of view PQC cannot be trusted

[citation needed]

https://words.filippo.io/crqc-timeline/#fn:lattices

by FiloSottile

4/7/2026 at 4:34:46 AM

Just a little selections of recent attacks on a few post quantum assumptions:

Isogenie/SIDH: https://eprint.iacr.org/2022/975

Lattices: https://eprint.iacr.org/2023/1460

Classical McEliece: https://eprint.iacr.org/2024/1193

Saying that you can trust blindly PQ assumptions is a very dangerous take.

by Tyyps

4/7/2026 at 2:50:16 PM

I don't think you said (or cited) what you think you said.

Leaving aside that you actually didn't cite a lattice attack paper, the "dual attack" on lattice cryptography is older than P-256 was when Curve25519 was adopted to replace it. It's a model attack, going all the way back to Regev. It is to MLKEM what algebraic attacks were (are?) to AES.

You know you're in trouble in these discussions when someone inevitably cites SIDH. SIDH has absolutely nothing to do with lattices; in fact, it has basically nothing to do with any other form of cryptography. It was a wildly novel approach that attracted lots of attention because it took a form that was pin-compatible with existing asymmetric encryption (unlike MLKEM, which provides only a KEM).

People who bring up SIDH in lattice discussions are counting on non-cryptography readers not to know that lattice cryptography is quite old and extremely well studied; it was a competitor to elliptic curves for the successor to RSA.

With that established: what exactly is the point you think those three links make in this discussion? What did you glean by reading those three papers?

by tptacek

4/7/2026 at 8:36:19 AM

He's obviously not saying that you can "trust blindly" any PQ algorithm out there, just that there are some that have appeared robust over many years of analysis.

by ramchip

4/7/2026 at 9:10:47 AM

He is assessing that the risk of seeing a quantum computer break dlog cryptography is stronger than the risk of having post quantum assumptions broken, in particular for lattices.

One can always debate but we have seen more post quantum assumptions break during the last 15 years than we have seen concrete progress in practical quantum factorisation (I'm not talking about the theory).

by Tyyps

4/7/2026 at 1:04:10 AM

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.

by cyberax

4/7/2026 at 3:53:47 AM

No it's not. This is the wrong argument. It's telling how many people trying to make a big stink out of non-hybrid PQC don't even get what the real argument is.

by tptacek

4/7/2026 at 5:01:20 AM

?

I'm not entirely sure what's the problem?

by cyberax

4/7/2026 at 5:08:06 AM

It's definitely not that "The research on lattice-based crypto is still young compared to EC/RSA."

by tptacek

4/7/2026 at 5:54:08 AM

Perhaps you would care to enlighten us ignorant plebs rather than taunting us?

My understanding (obviously as a non expert) matches what cyberax wrote above. Is it not common wisdom that the pursuit of new and exciting crypto is an exercise filled with landmines? By that logic rushing to switch to the new shiny would appear to be extremely unwise.

I appreciate the points made in the article that the PQ algorithms aren't as new as they once were and that if you accept this new imminent deadline then ironing out the specification details for hybrid schemes might present the bigger downside between the two options.

I mean TBH I don't really get it. It seems like we (as a society or species or whatever) ought to be able to trivially toss a standard out the door that's just two other standards glued together. Do we really need a combinatoric explosion here? Shouldn't 1 (or maybe 2) concrete algorithm pairings be enough? But if the evidence at this point is to the contrary of our ability to do that then I get it. Sometimes our systems just aren't all that functional and we have to make the best of it.

by fc417fc802

4/7/2026 at 2:26:37 PM

Calling out a mistaken assertion isn't a "taunt".

by tptacek

4/7/2026 at 4:33:17 PM

"taunt" in the sense that you dangle some knowledge in front of people and make them beg, not "taunt" in the sense of "insult".

You said:

>"[...] don't even get what the real argument is."

and then refuse to explain what the "real" argument is. someone then asks for clarification and you say:

"It's definitely not [...]""

okay, cool! you are still refusing to explain what the "real" argument is. but at least we know one thing it isnt, i guess.

you haven't even addressed the "mistaken assertion". you just say "nah" and refuse to elaborate. which is fine, i guess. but holy moly is it ever frustrating to read some of your comment chains. it often appears that your sole goal in commenting is to try and dunk on people -- at least that is how many of your comments come across to me.

by john_strinlai

4/7/2026 at 4:45:31 PM

I was explicit about what the real argument isn't: the notion that lattice cryptography is under-studied compared to RSA/ECC.

I understand what your takeaway from this thread is, but my perspective is that the thread is a mix of people who actually work in this field and people who don't, both sides with equally strong opinions but not equally strong premises. The person I replied to literally followed up by saying they don't follow the space! Would you have assumed that from their preceding comment?

(Not to pick on them; acknowledging that limitation on their perspective was a stand-up move, and I appreciate it.)

You do "XYZ isn't the right argument, ABC is" on a thread like that, and the reply tends to be "well yeah that's what I meant, ABC is just a special case of XYZ". No thanks.

by tptacek

4/7/2026 at 5:19:18 PM

I'm not a professional cryptographer, but I _am_ really interested in opinions of experts in the field and I do have a lot of prior experience with crypto (the actual kind, not *coin). From my point of view, I just don't see what's the fuss is all about.

by cyberax

4/7/2026 at 5:23:31 PM

I'm really not looking to drill further into the comment you wrote. I think we've converged on a shared understanding at this point.

by tptacek

4/7/2026 at 6:26:05 PM

There's no shared understanding, just a snarky expert claiming (in effect) "I know better than all you simpletons but I'm not going to share". At best it's incredibly poor behavior. At worst it's the behavior of someone who doesn't actually have a defensible point to make.

by fc417fc802

4/7/2026 at 7:44:24 PM

:thatsbait:

by tptacek

4/7/2026 at 11:59:21 AM

[dead]

by cindyllm

4/7/2026 at 5:23:53 AM

Uhm...?

As far as I know, the currently standardized lattice methods are not known to be vulnerable? And the biggest controversy seemed to be the push for inclusion of non-hybrid methods?

I'm not following crypto closely anymore, I stopped following the papers around 2014, right when learning-with-errors started becoming mainstream.

by cyberax

4/6/2026 at 7:27:13 PM

We can disagree on the tradeoff, but if you see no upside, you are missing the velocity cost of the specification work, the API design, and the implementation complexity. Plus the annoying but real social cost of all the bikeshedding and bickering.

by FiloSottile

4/7/2026 at 4:28:26 AM

All of those are costs are at least as high for non-hybrid. The spec and API are just as easy to design (because we have really good and simple ECC libraries), and the bikeshedding and bickering will be a lot less if people stop trying to force pure PQC algorithms that lots of people see as incredibly risky for incredibly little benefit.

by adgjlsfhk1

4/7/2026 at 4:25:04 AM

Indeed anti-hybrids arguments are very dangerous takes at best. People are putting a tremendous amount of faith in very understudied assumptions, in particular given the complexity of geometric relations and the structure of current lattice based scheme.

by Tyyps

4/6/2026 at 5:45:42 PM

I missed you at the most recent CRFG meeting.

by OhMeadhbh

4/6/2026 at 7:11:55 PM

The argument to skip hybrid keys sounds dangerous to me. These algorithms are not widely deployed and thus real world tested at all. If there is a simple flaw, suddenly any cheap crawler pwns you while you tried to protect against state actors.

by kro

4/6/2026 at 11:07:18 PM

This is the first well reasoned write up which makes me walk back from my "QC is irrelevant, and RSA is fine" position a bit. Well done! Thank you for putting this into terms a skeptic can relate to and understand. It helped me re-frame my thinking on risks here.

by ggm

4/7/2026 at 1:12:33 AM

A huge part of that, for me, was this from Scott Aaronson:

> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

That quote, alone, removed a lot of assumptions I had been carrying around.

by tennysont

4/7/2026 at 2:48:21 AM

Can anyone give the next layer of detail here? I understand the implications of this analogy, but looking for the underlying reasons the analogy is apt.

by rogerrogerr

4/7/2026 at 6:55:12 AM

AIUI, the scientists achieved a self-sustaining nuclear chain reaction around 1943. That was the hard part, not even a small bomb yet, but a bomb just needed more fuel and scale.

Fault tolerance is the hard part for QC, once it's achieved, the difference between factoring 35 and RSA-2048 is an engineering challenge, not an impossibility.

by apt-apt-apt-apt

4/7/2026 at 7:30:57 AM

Fault tolerance is a hard problem, assembling qubits for simultaneous gate operations is another hard problem. There are several dozen others.

It is exceptionally unlikely CRQC will be achieved in our lifetimes, if ever. The closer example is economically-viable fusion power production, which today has better odds than CRQC but remains solidly in the "maybe" zone after decades of global investment. Even though fusion weapons had been achieved half a century beforehand.

The bombs were actually relatively easy problems, in the scheme of things.

It is never wise to listen to people who's jobs and funding are connected to the development of a technology on when that technology will arrive. The answer is always "soon".

by nickelpro

4/7/2026 at 9:39:56 AM

Fusion also came to my mind but after thinking about it for longer I think it's a bad argument. The challenge with fusion is mostly around scale and efficiency to make it competitive against other energy sources (and net energy positive in the first place).

For CRQC it doesn't matter if they're massive expensive energy monsters. Even being able to break a single chosen key is enough to be a problem and once you can do one you can definitely do ten or a hundred.

by tempay

4/7/2026 at 10:12:04 AM

They're just different definitions of success.

For fusion the bar is "economically viable", in the current discussion for QC the bar is "cryptographically relevant".

They are comparable in that to meet either criteria, a variety of unsolved engineering challenges need to be overcome. For both, some of those problems have no clear and obvious solutions to which a simple application of resources and time will achieve.

Currently unknown innovations are required, unknown unknowns lurk in the dark corners, and all projections are relying on the assumption such innovations will arrive in a timely fashion and the unknown unknowns will be harmless glitches.

Neither are likely impossible, but betting on timelines is a fools game. This isn't the NYT publishing man-made flight is a million years away 2 months before the Wright brothers flew at Kitty Hawk, waiting for the right conglomeration of otherwise sound engineering to materialize in one place. It's like saying level 5 self-driving cars are two years away, a perpetually delayed technology for which all problems are well known and no new innovations are imminent.

by nickelpro

4/7/2026 at 10:53:31 AM

That quote alone proves that the author knows nothing about nuclear physics.

There is a critical flux/density/mass threshold for nuclear bombs. You can create small nuclear explosions with particle accelerators, which is how it all started. You just cannot scale those accelerators to anything macroscopic. But the microscopic explosions where done very very early, otherwise nobody would have had the necessary data to later extrapolate this to larger scales.

The interesting question after that first discovery of fission was only about how large the critical density or mass would be for a self-sustaining reaction. But as soon as you knew the critical mass, and had enough fissile material to go over that threshold, things became feasible, and easier with even more material.

Quantum computing doesn't have such a threshold, quite the opposite. As far as we know, larger problem sizes and larger numbers of qbits make things harder. Quantum error correction only changes the exponent in that relation.

by thyristan

4/6/2026 at 5:52:45 PM

Building out a supercomputer capable of breaking cryptography is exactly the kind of thing I expect governments to be working on now. It is referenced in the article, but the analogy to the Manhattan Project is clear.

Prior to 1940 it was known that clumping enough fissile material together could produce an explosion. There were engineering questions around how to purify uranium and how to actually construct the weapon etc. But the phenomenon was known.

I say this because there’s a meme that governments are cooking up exotic technologies behind closed doors which I personally tend to doubt.

This is almost perfect analogy to the MP though. We know exactly what could happen if we clumped enough qubits together. There are hard engineering challenges of actually doing so, and governments are pretty good at clumping dollars together when they want to.

by janalsncm

4/6/2026 at 7:12:20 PM

> There were engineering questions around how to purify uranium and how to actually construct the weapon etc. But the phenomenon was known.

FWIW, constructing a weapon with highly enriched uranium is, relatively, simple. At the time, the choice was made to use a gun-type weapon that shot a projectile of highly enriched uranium into a a "target" of highly enriched uranium. The scientists were so sure it would work that the design didn't necessitate a live test. This was "little boy", which was eventually dropped on Hiroshima.

Fat Man utilized plutonium which required an implosion to compress the fissile material that would set off the chain reaction. This is a much more complex undertaking, but it's much more efficient. Namely, you need much less fissile material, and more of that fissile material is able to participate in the chain reaction. This design is what allows for nuclear tipped missiles. The same principles can be applied to a U-235 based weapon as well.

The implosion based design is super interesting to read about. One memorable aspect is that the designers realized that applying a tamper of uranium (U-238) around the fissile material allows for significant improvement in yield. The chain reaction is exponential, so the few extra nanoseconds that the uranium keeps the fissile material together leads to significant increase in yield.

https://en.wikipedia.org/wiki/Little_Boy

https://en.wikipedia.org/wiki/Fat_Man

by O3marchnative

4/6/2026 at 11:18:45 PM

>I say this because there’s a meme that governments are cooking up exotic technologies behind closed doors which I personally tend to doubt.

Like when the government made XKeyscore[1]?

[1] https://en.wikipedia.org/wiki/XKeyscore

by Cider9986

4/6/2026 at 11:43:40 PM

What's exotic about XKeyScore?

by tptacek

4/7/2026 at 5:10:57 AM

>governments are cooking up exotic technologies behind closed doors which I personally tend to doubt.

You don't use zero days immediately. You stockpile them for when the time is right. A quantum computer is the ultimate zero day.

by burnerRhodov2

4/7/2026 at 7:12:02 AM

Maybe I should be more clear. Quantum computers already exist. Nuclear fission was already known about prior to the manhattan project.

When I say they’re not hiding “exotic technologies” I’m referring to things that would at a minimum win a Nobel prize. Alien technologies like antigravity or faster than light travel that people sometimes talk about. I am not even talking about things like Stuxnet which was impressive but not revolutionary.

by janalsncm

4/6/2026 at 6:19:26 PM

The Manhattan project employed some significant % of all of America. A project of that scale will likely never happen again.

It was also about far more than the science. It was about industrializing the entire production process and creating industrial capability that simply did not exist before.

by bitexploder

4/6/2026 at 6:33:11 PM

My comment was not limited to the U.S. government.

And the Manhattan Project cost $30B in today’s money. Compared with some of the numbers Congress has allocated recently, I’d call that a bargain.

by janalsncm

4/6/2026 at 11:27:48 PM

I am skeptical you could do something of that scale for 30B today. That is just the dollar cost based on inflation. If you used CPI indexing probably hundreds of billions to a trillion dollars now.

by bitexploder

4/6/2026 at 7:19:26 PM

Does quantum computing need that though? We don't suddenly need a large, unique supply chain for these computers. We don't need to dig up the qubits and refine them. Testing doesn't blow up the computer.

by bastawhiz

4/6/2026 at 11:32:10 PM

The Manhattan project had a huge impact but it was not that big as far as efforts in the war went (they managed to hide the budget allocated to the project from most of congress, for example).

by rcxdude

4/7/2026 at 5:46:00 AM

Yeah and some of the figures often quoted like consuming 14% of the electricity produced in the US are wrong, it was below 1%. https://ui.adsabs.harvard.edu/abs/2011APS..APRH13004R/abstra...

by brohee

4/7/2026 at 12:56:24 PM

It was like 0.5% GDP. It wasn’t insane, but still, you are right.

It was very focused. What do we get out of the F-35 program? By comparison, it has eaten (projected total lifetime cost) 2 trillion dollars. It is 4.5% of the GDP. I had no idea. This is just a military and government contractor subsidy. What are we doing…

by bitexploder

4/7/2026 at 3:00:11 PM

That's $ 2 trillion over the course of 20 years, so by your own numbers 0.23% of GDP.

by fluoridation

4/6/2026 at 6:49:55 PM

Yeah, sounds like it's time to take this very seriously. Sobering article to read, practical and to the point on risk posture. One brief paragraph though that I think deserves extra emphasis and I don't see in the comments here yet:

>In symmetric encryption, we don’t need to do anything, thankfully

This is valuable because it does offer a non-scalable but very important extra layer that a lot of us will be able to implement in a few important places today, or could have for awhile even. A lot of people and organizations here may have some critical systems where they can make a meat-space-man-power vs security trade by virtue of pre-shared keys and symmetric encryption instead of the more convenient and scalable normal pki. For me personally the big one is WireGuard, where as of a few years ago I've been able to switch the vast majority of key site-to-site VPNs to using PSKs. This of course requires out of band, ie, huffing it on over to every single site, and manually sharing every single profile via direct link in person vs conveniently deployable profiles. But for certain administrative capability where the magic circle in our case isn't very large this has been doable, and it gives some leeway there as any traffic being collected now or in the future will be worthless without actual direct hardware compromise.

That doesn't diminish the importance of PQE and industry action in the slightest and it can't scale to everything, but you may have software you're using capable of adding a symmetric layer today without any other updates. Might be worth considering as part of low hanging immediate fruit for critical stuff. And maybe in general depending on organization and threat posture might be worth imagining a worst-case scenario world where symmetric and OTP is all we have that's reliable over long time periods and how we'd deal with that. In principle sneakernetting around gigabytes or even terabytes of entropy securely and a hardware and software stack that automatically takes care of the rough edges should be doable but I don't know of any projects that have even started around that idea.

PQE is obviously the best outcome, we ""just"" switch albeit with a lot of increase compute and changed assumptions in protocols pain, but we're necessarily going to be leaning on a lot of new math and systems that won't have had the tires kicked nearly as long as all conventional ones have. I guess it's all feeling real now.

by xoa

4/7/2026 at 1:02:34 AM

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.

by wuiheerfoj

4/6/2026 at 9:39:19 PM

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

by btdmaster

4/6/2026 at 9:53:32 PM

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

by Avamander

4/6/2026 at 9:56:29 PM

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

by FiloSottile

4/7/2026 at 1:06:46 AM

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.

by cassonmars

4/7/2026 at 1:29:04 AM

The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.

by FiloSottile

4/7/2026 at 1:32:04 AM

As you are someone building cryptographic libraries used by people all over the world, which includes those who might be seen as "enemies" by the organization in question, this is not a gradient — it's quite binary in nature.

by cassonmars

4/7/2026 at 10:46:10 AM

Maybe your motives are benevolent, but you're arguing two things:

1) We can broadly trust the US government 2) We should adopt new encryption partly designed and funded by the US government, and get rid of the battle tested encryption that they seem not to be able to break

Forgive me for being somewhat suspicious of your motives here

by ifwinterco

4/8/2026 at 5:49:38 AM

[We can broadly trust the US government] not to promote broken encryption to its own agencies.

by caf

4/6/2026 at 11:05:16 PM

> 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

NSA still has the secret Suite A system for their most sensitive information. If they think that is better than the current public algorithms and their goal is to make telecommunications vendors to have better encryption, then why doesn't they publish those so telco could use it?

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

The NSA weakened DES against brute-force attack by reducing the key size (while making it stronger against differential cryptanalysis, though).

https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's...

Also NSA put a broken cipher in the Clipper Chip (beside all the other vulnerabilities).

by raron

4/7/2026 at 8:10:44 PM

The thing that sets this effort apart from DES and Clipper is that USG actually has skin in the game. Neither DES or Clipper were ever intended or approved to protect classified information.

These are algorithms that NSA will use in real systems to protect information up to the TOP SECRET codeword level through programs such as CNSA 2.0[1] and CsFC.

[1] https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA...

[2] https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...

by bigfatkitten

4/6/2026 at 11:09:18 PM

> 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

I guess the NSA thinks they're the only one that can target such a side channel, unlike, say, a foreign government, which doesn't have access to the US Internet backbone, doesn't have as good mathematicians or programmers (in NSA opinion), etc.

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

Except for KyberSlash (I was surprised when I looked at the bug's code, it's written very optimistically wrt what the compiler would produce...)

So do you think vendors will write good code within the deadlines between now and... 2029? I wouldn't bet my state secrets on that...

by btdmaster

4/6/2026 at 11:13:27 PM

> KyberSlash

That's a timing side-channel, irrelevant to ephemeral key exchanges, and tbh if that's the worst that went wrong in a year and a half, I am very hopeful indeed.

by FiloSottile

4/6/2026 at 7:06:14 PM

I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good.

Age should be using 256 bit file keys, and default to PC keys in asymmetric mode.

by aborsy

4/6/2026 at 9:12:59 PM

> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys

It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.

My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.

by FiloSottile

4/6/2026 at 7:13:11 PM

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

by cwmma

4/6/2026 at 8:36:24 PM

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 ok

Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments

by lucb1e

4/6/2026 at 8:41:08 PM

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

by tptacek

4/7/2026 at 1:05:54 AM

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

by lucb1e

4/7/2026 at 3:05:11 AM

The moment you say "lot of cases", multiply the cost by $100,000,000.

by tptacek

4/7/2026 at 7:13:16 PM

lol, sure

by lucb1e

4/7/2026 at 5:50:45 AM

I'm working on just that in some IoT context, and a lots of chips I have to deal with only have hardware support for AES-128, so it's a little more complicated...

by brohee

4/6/2026 at 7:21:20 PM

How would he know? Did he publish papers on it?

You can’t just throw “Grover’s algorithm is difficult to parallelize” etc. It’s not same as implementation, especially when it gets to quantum computers. It’s very specialized.

by aborsy

4/6/2026 at 8:28:53 PM

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

by codethief

4/6/2026 at 11:35:29 PM

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

by rcxdude

4/7/2026 at 12:46:00 AM

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

by codethief

4/7/2026 at 9:13:52 AM

I mean, if you're worried about Signal being a bad actor you also should probably be worried about Intel being a bad actor, and they hold the keys to SGX (especially because the biggest threat, if you're worried about this at all, is going to be governments compelling the involved companies to hand over data or attempt to intercept messages). And Signal is also a third party to your communications, that's how it works. But nothing about SGX makes me think Signal is more trustworthy, it doesn't meaningfully remove actions that they could take to compromise my communications.

by rcxdude

4/7/2026 at 4:09:47 PM

Agreed, I never put much trust in Intel SGX, either. I was bringing up the whole topic rather because I'm secretly hoping it will force Signal to revisit the whole Signal PIN debacle and they will ultimately find a better solution.

by codethief

4/6/2026 at 8:33:06 PM

Signal uses SGX for features every other mainstream E2E messenger does in serverside plaintext.

by tptacek

4/6/2026 at 11:16:24 PM

If by "mainstream E2E messenger" you mean WhatsApp and Facebook Messenger, sure. But I didn't realize those were the benchmark these days.

by codethief

4/6/2026 at 11:39:51 PM

What's the mainstream messenger you're considering that doesn't maintain serverside contact lists?

by tptacek

4/7/2026 at 1:08:56 AM

I never said I was considering any.[0] I'm strictly interested in what Signal is doing to keep (or even improve) its security guarantees.

On that note, Signal wouldn't even depend on Intel SGX for security nearly as much if Signal PINs weren't user-chosen but instead auto-generated with enough entropy. Yes, contact discovery through phone numbers would still be challenging, but secure value recovery[1] just requires a key with enough entropy.

[0]: For the record, Threema doesn't store your contact list server-side, unless you explicitly opt in. Similarly, now that Signal supports usernames, my understanding is that one could use the app without uploading one's contact list in plaintext.

[1]: https://signal.org/blog/secure-value-recovery/

by codethief

4/7/2026 at 3:18:03 AM

One of the author is from the Ethereum Foundation. Super interesting paper to read. This goes beyond just cryptocurrency. I wrote about it here a while ago: https://kaveh.page/blog/bitcoin-quantum-threat

by kwar13

4/7/2026 at 8:50:03 PM

Side question, but does anyone know why specifically 2^-32 is the target floor for attacker success (in footnote 3)? I found another mention of the 2^-32 target in [0], but I'm not even certain they're related.

[0] https://csrc.nist.gov/csrc/media/Events/2023/third-workshop-...

by nathanmcrae

4/6/2026 at 6:10:11 PM

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 Android Keystore, for that matter)?

by palata

4/6/2026 at 6:17:23 PM

This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them.

They/we need to migrate those protocols to PQ now, so that you all can start migrating to PQ keys in time, including the long tail of users that will not rotate their keys and hardware the moment the new algorithms are supported.

For example, it might be too late to get anything into Debian for it to be in oldstable when the CRQCs come!

by FiloSottile

4/6/2026 at 8:42:06 PM

> This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them.

Sure, I'm just trying to understand the consequences of that. Felt great to finally have secure elements on smartphones and laptops (or Yubikeys), protecting against the OS being compromised (i.e. "you access my OS, but at least you can't steal my keys").

I was wondering if PQ meant that when it becomes reality, we just get back to a world where if our OS is compromised, then our keys get compromised, too. Or if there is a middle ground in the threat model, e.g. "it's okay to keep using your Yubikey, because an attacker would need to have physical access to your key, specialised hardware AND access to a quantum computer in order to break it". Versus "you can stop bothering about security keys because with "store now, decrypt later", everything you do today with your security keys will anyway get broken with quantum computers eventually".

by palata

4/6/2026 at 9:19:42 PM

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 hybrid software ML-KEM-768 + hardware P-256 keys as soon as they are available (https://github.com/str4d/age-plugin-yubikey/pull/215). 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. In the meantime, depending on your threat model and the longevity of your secrets (and how easily they can rotated in 1-2 years), it might make sense to switch to software PQ keys.

by FiloSottile

4/6/2026 at 9:30:47 PM

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"?

by palata

4/6/2026 at 10:07:29 PM

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.

by FiloSottile

4/6/2026 at 10:26:47 PM

Oh right, I got it now!

by palata

4/6/2026 at 6:15:23 PM

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.

by amluto

4/6/2026 at 8:51:19 PM

> If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks.

Let me rephrase it to see if I understand correctly: so it is fine to keep using my security keys today for authentication (e.g. FIDO2?), but everything else should use PQ algorithm because the actual data transfers can be stored now and decrypted later.

Meaning that today (and for a few years), my Yubikey still protects me from my key being stolen when my OS is compromised.

Correct?

by palata

4/7/2026 at 1:21:12 AM

Sounds right to me.

by amluto

4/6/2026 at 8:04:43 PM

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.

by elevation

4/6/2026 at 8:40:21 PM

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?

by ls612

4/6/2026 at 10:23:00 PM

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.

by ameliaquining

4/7/2026 at 4:13:23 AM

I think people have to be extremely careful with this kind of opinion. In particular seeing such a push for post-quantum crypto while the current state of the art for quantum factorisation is 15 and 21 and the fact that current assumptions (for KEM in particular) are clearly not as studied as dlog.

It's maybe good to remember that SIDH was broken in polynomial time by a classical computer 3 years ago... I'm really concerned by the current rush for PQ solutions and what are the real intentions behind it. On a side note there might even be a world where a powerfully enough quantum computer that break 2048 bigs RSA will never exists (Hooft, Palmer... Recent quantum gravity theory).

by Tyyps

4/7/2026 at 5:05:18 AM

The largest number factorised on a quantum computer is 8,219,999 on a D-Wave machine (a quantum annealer, so not capable of running Shor's, but capable of being an actual shipping product you can use, unlike gate model machines).

https://www.nature.com/articles/s41598-024-53708-7

> Overall, 8,219,999 = 32,749 × 251 was the highest prime product we were able to factorize within the limits of our QPU resources. To the best of our knowledge, this is the largest number which was ever factorized by means of a quantum annealer; also, this is the largest number which was ever factorized by means of any quantum device without relying on external search or preprocessing procedures run on classical computers.

by mikestorrent

4/7/2026 at 11:40:52 AM

You should read the article you posted before you write a comment. Hint: check P_F=0 in tables 2, 3 and 4.

"Factored" is doing a lot of lifting here and is borderline deceptive. Plenty of researchers have long ago pointed out that this won't scale, see M Mosca for reference.

by William_BB

4/8/2026 at 2:44:32 AM

I'm aware; I don't think gate model machines have demonstrated much potential of scaling in practice any time soon so this is more of a lark to show how unimpressive the current Shor's attempts have been

by mikestorrent

4/7/2026 at 6:00:49 AM

The D-Wave machine doesn't benefit from the quantum speedups discussed in the article

by nextaccountic

4/7/2026 at 7:44:51 AM

This is quantum annealing and it has nothing to do with Shor (I should have been precise sorry).

It is not clear at all that quantum annealing provides any speedup compared to a classical computer.

by Tyyps

4/8/2026 at 2:45:21 AM

Yeah that was the first line of my comment.

Annealing is in fact proven to be able to do certain things faster than any classical CPU; whether you can make use of that particular feature is a different question. If you're into spinglasses, maybe

by mikestorrent

4/7/2026 at 5:32:42 AM

As long as a hybrid approach is taken what is there to worry about? Whereas not adopting PQC in a timely manner is obviously a gamble.

by fc417fc802

4/7/2026 at 7:47:47 AM

I agree, but the blog post was specifically ruling out hybrid approach.

by Tyyps

4/7/2026 at 8:24:07 AM

> I'm really concerned by the current rush for PQ solutions and what are the real intentions behind it.

You had written. As long as we're in agreement that rushing PQ appears to be the appropriate choice. The only question is the precise form it should take, with the author arguing that hybrid would be unacceptably slow to roll out due to various social and bureaucratic reasons.

He's also pointing out that the only scenario in which hybrid is of benefit is one in which crypto related QC remains either relatively ineffective or extremely expensive in the medium term. Since that assumption is looking increasingly suspect it calls into question the point of hybrid to begin with. In the face of cheap QC hybrid adds zero value.

by fc417fc802

4/7/2026 at 9:23:30 AM

I think it is pretty direct from my comment that if you use a hybrid approach (done correctly) you can rely on the hardness of dlog based assumption and therefore my comment on potential weakness of PQ assumptions can be ruled out. In this way we disagree that rushing PQ is the appropriate choice if it rules out dlog based security.

> He's also pointing out that the only scenario in which hybrid is of benefit is one in which crypto related QC remains either relatively ineffective or extremely expensive in the medium term. Since that assumption is looking increasingly suspect it calls into question the point of hybrid to begin with. In the face of cheap QC hybrid adds zero value.

This is exactly what I'm pointing out as extremely dangerous. My take was that the risk of seeing a quantum computer breaking dlog in a near future isn't stronger than breaking PQ assumptions in a near future.

by Tyyps

4/7/2026 at 6:37:26 PM

You seem to just be rehashing what we already clearly agree on. Obviously if you view classically breaking PQ algorithms as higher likelihood than QC breaking classical then you are going to disagree with the premise.

Can you actually back up your prediction that crypto related QC will remain either relatively ineffective or extremely expensive in the medium term?

by fc417fc802

4/8/2026 at 2:48:15 AM

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 the likelihood of CRQCs breaking ECC is pretty high (>50% by 2040) and the odds of classically breaking lattices is low (<1% by 2050), but creating a 0.5% chance of breaking cryptography for the entire world seems way to high when we have a free mitigation right here.

by adgjlsfhk1

4/8/2026 at 6:30:12 AM

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 with the aforementioned premise that we should switch to a PQ only scheme making use of said algorithm. Rehashing that is just stating the obvious.

What wasn't presented was any reasoning to back an elevated risk assessment for any particular PQ algorithm, of which there are several. So at that point the "argument" amounts to little more than "nuh-uh, that risk assessment is wrong" which isn't exactly convincing or insightful.

by fc417fc802

4/8/2026 at 4:59:30 PM

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

by adgjlsfhk1

4/7/2026 at 12:06:52 AM

> 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 in the same way we are not experts in theirs.

The zero-knowledge proof may come across as something of a gimmick, but two of the authors (Justin Drake and Dan Boneh) have strong ties to cryptocurrency communities, where this sort of thing is not unusual.

I also don’t think it’s particularly strange to focus on cryptocurrencies. This is one of the few domains where having access to a quantum computer ahead of others could translate directly into financial gain, so the incentive to target cryptocurrencies is quite big.

Changing the cryptographic infrastructure we rely on daily is difficult, but still easier than, for example in Bitcoin, where users would need to migrate their coins to a quantum-resistant scheme (whenever such a scheme will be implemented). Given the limited transaction throughput, migrating all vulnerable coins would take years, and even then, there would remain all those coins whose keys have been lost.

Satoshi is likely dead, incapacitated, or has lost or destroyed his keys, and thus will not be able to move his coins to safety. Even if he has still access, the movement of an estimated one million BTC, which are currently priced in by the market as to be permanently lost, would itself be a disruptive price event, regardless if done with good or bad intentions.

If you know which way the price will go (obviously way down in this case), you can always profit from such a price move, even if Satoshi's coins were blacklisted and couldn't be sold directly.

by bhaak

4/8/2026 at 12:02:00 PM

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

by xorcist

4/7/2026 at 6:13:31 AM

"This is one of the few domains where having access to a quantum computer ahead of others could translate directly into financial gain"

Doubt, the moment people get vocal about their fund being stolen that will be it for crypto, it will crash the bank run. The only way it could work is that if you steal too little to be noticed, which will also be too little to finance your venture...

by brohee

4/7/2026 at 6:59:41 AM

May I introduce you to a concept called "shorting"? You can make money from falling prices without selling the stolen coins. As I said just moving Satoshi's coins would lead to lots of panic selling.

The snarky reply would be that having their funds stolen is not something that seems to discourage people from having cryptocurrencies as it happens all the time:

https://www.web3isgoinggreat.com/

by bhaak

4/7/2026 at 1:34:38 AM

> Given the limited transaction throughput, migrating all vulnerable coins would take years ...

How? I just googled: about 55 million addresses with bitcoin in them, about 144 blocks per day, about 3000 to 5000 tx per block.

In something like 100 days all the coins would be moved to other addresses.

I gotta say it'd be hilarious if to speed up that migration-to-quantum-resistant-addresses process, the Bitcoin community were to finally allow bigger blocks.

EDIT: I take it if the network had to have full blocks for 100 days, then "shit would happens". Maybe they should force an orderly move: e.g. only addresses ending with "3a" are eligible to be moved in a block whose hash ends with an "3a", etc. to prevent congestion?

by TacticalCoder

4/7/2026 at 6:56:45 AM

The signatures would be larger than they are today. The article touches on it but doesn't give any estimates. What I read online were claims from 10 to 100 times larger than currently.

This paper claims 60-70% throughput loss with 59 times(!) larger storage space requirements.

https://jbba.scholasticahq.com/article/154321.pdf

by bhaak

4/6/2026 at 8:19:47 PM

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?

by upofadown

4/6/2026 at 5:29:51 PM

In rebuttal, Peter Gutmann seems to think the progress towards quantum computing devices which can break commonly used public key crypto systems is not moving especially quickly: https://eprint.iacr.org/2025/1237

by OhMeadhbh

4/6/2026 at 5:35:11 PM

That's not a rebuttal. The post references the paper and a rebuttal to it from an expert in the field.

by schmichael

4/6/2026 at 7:23:27 PM

>and a rebuttal to it from an expert in the field.

while i agree with filippo, the way you worded this makes me think that you may not be aware that gutmann is also an expert in the field. so, if you are giving filippo weight because he is an expert, it is worth giving some amount to gutmann as well.

by john_strinlai

4/6/2026 at 7:24:52 PM

I apologize if I flippantly dismissed the fact that experts disagree. That was not my intention. I was trying to point out that OP does address the referenced counter-point post specifically.

by schmichael

4/6/2026 at 7:29:19 PM

>Sorry if I flippantly dismissed the fact that experts disagree!

i dont really get your reply/insincere apology.

if you are going to bother mentioning filippo's expertise in the first place, its just weird to frame it the way you did. that is how someone would typically dismiss some random blogger with an appeal to authority. but if both people are authorities, it doesnt make sense.

if you already knew, than my comment can be context for future readers that dont and might just dismiss gutmann as a non-expert getting rebutted by an expert.

by john_strinlai

4/6/2026 at 5:40:56 PM

Damn. It's like I insulted Vault.

Also, I went over Filippo's post again and still can't see where it references the Gutmann / Neuhaus paper. Are we talking about the same post?

by OhMeadhbh

4/6/2026 at 6:24:48 PM

From the abstract:

> This paper presents implementations that match and, where possible, exceed current quantum factorisation records using a VIC-20 8-bit home computer from 1981, an abacus, and a dog.

From the link:

> 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[1]. As Scott Aaronson said[2]:

> > Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

[1]: https://bas.westerbaan.name/notes/2026/04/02/factoring.html

[2]: https://scottaaronson.blog/?p=9665#comment-2029013

by xvector

4/6/2026 at 6:23:33 PM

From Filippo's post: "Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums."

by tkhattra

4/6/2026 at 7:21:39 PM

Is that even a rebuttal? Seems like just a dismissal without any substance. I expect in 10 years the predictions will be wrong, kind of like Y2K all over again.

by commandersaki

4/6/2026 at 9:00:18 PM

If only we had a technology where an author could specify a unique identifier and name of another author's paper. Something that could cite a different paper and link to it.

by OhMeadhbh

4/6/2026 at 6:35:56 PM

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

by Animats

4/6/2026 at 7:24:53 PM

The bitcoins won't move until the technology is commoditized (ie well past mainstream usage by the government.)

Having PQ and your adversaries not knowing is far more valuable than the few hundred billion you could get from cracking (and tanking) BTC.

by xvector

4/6/2026 at 9:26:02 PM

No, it will likely be a state actor who reaches it first, who will never give away such a capability so easily

by oncallthrow

4/6/2026 at 6:57:07 PM

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 Ethereum as another erc20 token

- [0] https://pq.ethereum.org/

by sunshine-o

4/6/2026 at 8:40:56 PM

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 signing time is irrelevant.

To the extent that I've seen any opposition related to this isn't only been in related to schemes that were to inefficient or related to proposals to confiscate the assets of people not adopting the proponent's scheme (which immediately raises concerns about backdoors and consent).

There is active development for PQ signature standards tailored to Bitcoin's needs, e.g. https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-sig... and I think progress looks pretty reasonable.

Claims that there is no development are as far as I can tell are just backscatter from a massive fraud scheme that is ongoing (actually, at least two distinct cons with an almost identical script). There are criminal fraudsters out seeking investments in a scheme to raise money to build a quantum computer and steal Bitcoins. One of them reportedly has raised funds approaching a substantial fraction of a billion dollars from victims. For every one sucker they convince to give them money, they probably create 99 others people panicked about it (since believing it'll work is a pre-req to handing over your money).

by nullc

4/7/2026 at 3:36:19 AM

> proposals to confiscate the assets of people not adopting the proponent's scheme (which immediately raises concerns about backdoors and consent)

They're going to lose those assets regardless, either to the first hacker with a QC or via a protocol-level burn. The latter is arguably better for the network's long-term health, as it reduces circulating supply rather than subsidizing an attacker.

I can understand disagreeing about timelines but is there a flaw in the logic that once the underlying crypto is broken, "consent" is a moot point?

by olalonde

4/7/2026 at 3:43:31 AM

[dead]

by ArguMisrepre

4/6/2026 at 8:00:15 PM

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

by PretzelPirate

4/6/2026 at 8:51:51 PM

Ethereum is way more complex than let's say Bitcoin and all parts are affected. This is not just the "signature scheme".

The fact that the signature size is multiplied by ~10 will greatly affect things like blockspace (what I guess is even more a problem with Bitcoin !)

Also they are the only blockchain I believe that put an emphasis on allowing large number of validators to run on very modest hardware (in the ballpark of a RPI, N100 or phone).

My understanding is they will need to pack it with a larger upgrade to solve all those problems, the so called zkVM/leanVM roadmap.

And then there are the L2 that are an integral part of the ecosystem.

So this is the greatest upgrade ever made on Ethereum, pretty much full rewrite, larger than the transition to proof of stake. I remember before the Proof of Stake migration they were planning to redo the EVM too (with something WASM based at the time) but they had to abandon their plan. Now it seems there is no choice but to do it.

by sunshine-o

4/7/2026 at 10:10:56 AM

The BLAKE3 angle here is interesting — we switched from SHA-256 to BLAKE3 for hash-chaining in a local multi-agent security orchestrator precisely because of this kind of forward-looking pressure. Not the same threat model, but the instinct to not build new systems on classical primitives feels validated by this post.

by NeoBild

4/6/2026 at 7:18:27 PM

I wonder, what is the impact of this to widely deployed smartcards like credit cards / EID passports?

Aren't they relying on asymmetrical signing aswell?

by kro

4/6/2026 at 8:40:22 PM

Yes. They will need to switch, so that hardware needs to be swapped out

by lucb1e

4/7/2026 at 12:45:00 AM

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/

by EdNutting

4/7/2026 at 12:46:56 AM

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.

by EdNutting

4/6/2026 at 6:07:56 PM

I was in this field a while back, and I always found it baffling that anyone ever believed in the earlier large estimates for the size of a quantum computer needed to run Shor's algorithm. For a working quantum computer, Shor's algorithm is about as difficult as modular exponentiation or elliptic curve scalar multiplication: if it can compute or verify signatures or encrypt or decrypt, then it can compute discrete logs. To break keys of a few hundred bits, you need a few hundred qubits plus not all that much overhead. And the error correction keeps improving all the time.

Also...

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

This part is embarrassing. We’ve had hash-based signatures that are plenty good for this for years and inspire more confidence for long-term security than the lattice schemes. Sure, the private keys are bigger. So what?

We will also need some clean way to upgrade WebAuthn keys, and WebAuthn key management currently massively sucks.

by amluto

4/6/2026 at 8:40:29 PM

> 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 cost of replacing all servers and OS ...

by hujun

4/6/2026 at 10:31:24 PM

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.

by amluto

4/7/2026 at 12:53:08 AM

[dead]

by RyujiYasukochi

4/7/2026 at 7:42:14 AM

Given that quantum computing (QC) can speed up training of neural networks (LLMs), it would be wise for Google to invest into QC as much as possible.

Google with Softbank invested about $230M into QC last year. Microsoft, IBM and Google have spent on QC $15B combined, through all of the time they researched it. $15B spent in 20 years, less than $1B per year, by three companies.

Google spent upwards of $150B last year in datacenters.

This may tell us something about how close we are to a working quantum computing.

by thesz

4/6/2026 at 4:45:18 PM

What do you recomend as reading material for someone that was in college a while ago (before AE modes got popular) to get up to speed with the new PQ developments?

by pdhborges

4/6/2026 at 5:00:18 PM

If you want something book-shaped, the 2nd edition of Serious Cryptography is updated to when the NIST standards were near-final drafts, and has a nice chapter on post-quantum cryptography.

If you want something that includes details on how they were deployed, I'm afraid that's all very recent and I don't have good references.

by FiloSottile

4/6/2026 at 6:30:24 PM

This would also be a good time for certain governments to knowingly push broken PQ KE standards while there is a panicked rush to get PQ tech in place.

by krunck

4/6/2026 at 6:42:11 PM

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 the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.

by FiloSottile

4/6/2026 at 7:06:21 PM

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.

by adgjlsfhk1

4/6/2026 at 7:40:09 PM

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.

by FiloSottile

4/6/2026 at 7:30:18 PM

> see for example DES's 56 bit key size

In fairness, that was from 1975. I don't particularly trust the NSA, but i dont think things they did half a century ago is a great way to extrapolate their current interests.

by bawolff

4/6/2026 at 11:18:06 PM

AFAIK they did a lot of illegal things in the Snowden-era, too.

by raron

4/6/2026 at 6:33:43 PM

Which governments are you thinking of?

by some_furry

4/7/2026 at 7:54:57 AM

For the uninitiated, could you share your perspective on how feasible quantum computing is? Isnt it built on quantum entanglement which seems to break universal speed limit? Is this a feasible engineer or just a scientists imagination?

by elwray

4/6/2026 at 8:00:24 PM

noob question: can't we just use longer classical keys, at least as a stop gap?

by griffzhowl

4/6/2026 at 9:24:46 PM

No, and even if we could, it would require a migration of approaching the same difficulty of a migration to PQ, at which point why not just migrate to PQ

by oncallthrow

4/7/2026 at 4:44:29 AM

I know this may be outside of scope but I am very curious as to any thoughts you may have of a potential for ternary system at hw level?

by sans_souse

4/6/2026 at 6:51:47 PM

This is exactly how customers who do threat modeling see PQC. HN can armchair QB this all they want, the real money is moving fast to migrate.

The analogy to a small atomic bomb is on point.

by scorpionfeet

4/7/2026 at 6:53:49 PM

Y2K 1.5

by hacker_88

4/7/2026 at 5:25:01 AM

> I simply don’t see how a non-expert can look at what the experts are saying, and decide “I know better, there is in fact < 1% chance.” Remember that you are betting with your users’ lives.

Problem is the experts don't tell the truth, they say whatever game theory version of the world they came up with will make people do what they think people should do. If experts just said the literal truth it'd be different, and then when they would walk it back would be understandable.

But when later it becomes clear the experts said outright lies because they thought it'd induce the right behavior, that goes out the window.

by vasco

4/6/2026 at 9:25:43 PM

The first and most obvious target will be Bitcoin. It’s market cap today is $1.4T. That’s a gigantic reward for any state actor or entity with the resources and budget to break it.

Does this mean Bitcoin is going to $0? Absolutely not, it’s just going to take the community organizing and putting in the gigantic effort to make the changes. Frankly I’m not personally clear if that means all existing cold wallets need to be flashed/replaced? All existing Bitcoin miner software needs to be updated? All existing Bitcoin node software needs to be updated?

by nodesocket

4/7/2026 at 9:07:17 AM

> It’s market cap today is $1.4T. That’s a gigantic reward for any state actor or entity with the resources and budget to break it.

The market cap of a cryptocurrency — or any commodity, really — is not its market value. If you have all bitcoins in existence and try to sell them you will crash the price to zero. The slope of that price graph — from the current market price to zero — determines how much you make in total. Most cryptocurrency exchanges have public order books, so you can see how much (and at what price per coin) you can actually sell into the market before you eat up all the bids. Last time I checked it was closer to $10bn than $1trn.

by runeks

4/6/2026 at 11:10:44 PM

Bitcoin value will plummet if people lose trust in it.

by goalieca

4/7/2026 at 10:07:05 AM

[flagged]

by enesz

4/6/2026 at 11:54:18 PM

[flagged]

by atlasagentsuite

4/7/2026 at 4:38:33 AM

TlDR:

The real problem is building a system that can survive noise, errors, and decoherence. Once you solve that, scaling it up is non-trivial but has a very exponential path.

by burnerRhodov2

4/6/2026 at 7:18:33 PM

RemindMe! 3 years "impending doom"

by commandersaki

4/6/2026 at 5:30:53 PM

Why do we "need to ship"? 1,000 qubit quantum computers are still decades away at this point

by OsrsNeedsf2P

4/6/2026 at 5:56:40 PM

So... In 2013 I was working for Mozilla adding TLS 1.1 and 1.2 support into Firefox. It turns out that some of the extensions common in 1.1, in some instances caused PDUs to grow beyond 16k (or maybe it was 32k, can't remember.). This caused middle boxes to barf. Sure, they shouldn't barf, but they did. We discovered the problem (or rather one of our users discovered the problem) by increasing the key size on server and client certs to push PDU sizes over the limit.

At the very least, you want to start using hybrid legacy / pqc algorithms so engineers at Cisco will know not to limit key sizes in PDUs to 128 bytes.

by OhMeadhbh

4/6/2026 at 6:11:48 PM

A few points here: There is already very wide use of PQ algorithms in the Web context [0], which is the most problematic one because clients need to be able to connect to any site and there's no real coordination between sites and clients. So we're exercising the middleboxes already.

The incident you're thinking of doesn't sound familiar. None of the extensions in 1.1 really were that big, though of course certs can get that big if you work hard enough. Are you perhaps thinking instead of the 256-511 byte ClientHello issue addressed ion [1]

[0] https://blog.cloudflare.com/pq-2025/ [1] https://datatracker.ietf.org/doc/html/rfc7685

by ekr____

4/6/2026 at 9:24:15 PM

Oh hey Eric. I think I was wrong saying it was 1.1. It was a middlebox that ignored max fragment negotiation, which I think was introduced in 1.2. IIRC, the middlebox claimed to support it for 1.2 connections, but silently failed by blackholing the connection. They eventually crafted a fix, but it was an annoying year waiting for network operators to upgrade the firmware on their routers.

by OhMeadhbh

4/7/2026 at 12:40:15 PM

[0] was an excellent read, thank you for sharing!

by jonasced

4/7/2026 at 3:25:04 AM

This issue is already being tracked by a shiny website: https://tldr.fail/

by kevvok

4/6/2026 at 5:38:53 PM

There is always a price to encryption. The cost goes up the more you have to cater to different and older encryptions while supporting the latest.

by Sparkyte

4/6/2026 at 5:39:39 PM

Yes, this is why I invested in QRL crypto. With lates updates and no T1 exchange it looks like a good opportunity to grow.

by munrocket

4/6/2026 at 6:27:02 PM

> Traveling back from an excellent AtmosphereConf 2026, I saw my first aurora, from the north-facing window of a Boeing 747.

Given the author's "safety first" stance on pqc, it seems a bit incongruent to continue to fly to conferences...

by bjourne

4/6/2026 at 4:59:58 PM

This seems like something uniquely suited to the startup ecosystem. I.e. offering PQ Encryption Migration as a Service. PQ algorithms exist and now theres a large lift required to get them into the tech with substantial possible value.

by vonneumannstan

4/6/2026 at 5:19:29 PM

… really? This is simultaneously so far down in the plumbing and extremely resistant to measuring the impact of, I can’t imagine anyone building a company off of this that’s not already deep in the weeds (lookin’ at you, WolfSSL).

The idea that a startup would be competitive in the VC “the only thing that matters are the feels” environment seems crazy to me.

by hlieberman

4/6/2026 at 5:34:31 PM

Yeah... I spent the 90s working for RSADSI and Certicom implementing algorithms. Crypto is a vitamin, not an aspirin. Hardly anyone is capable of properly assessing risk in general, much less the technical world of information risk management. Telling someone they should pay you money to reduce the impact of something that may or may not happen in the future is not a sales win.

by OhMeadhbh