Five years, ten years, or even longer? A timeline assessment of the threats posed by quantum computing.

CN
4 hours ago

Original Author: Justin Thaler (@SuccinctJT), a16z Research Partner

Original Translation: AididiaoJP, Foresight News

When will quantum computers be able to crack encryption? The timeline for this question is often exaggerated, leading to calls for an "urgent, comprehensive shift to post-quantum cryptography."

However, these calls often overlook the costs and risks of premature migration and ignore the fundamentally different nature of threats posed by different cryptographic tools:

  • Post-quantum encryption needs to be deployed immediately, regardless of the cost. This is because "steal now, decrypt later" attacks already exist. Sensitive data encrypted today will still hold significant value even if quantum computers emerge decades later. While post-quantum encryption has performance losses and implementation risks, we have no choice for data that requires long-term confidentiality.
  • Post-quantum digital signatures are a different matter. They are not easily susceptible to the aforementioned "steal now, decrypt later" attacks, and their own costs and risks (increased size, performance overhead, immature schemes, potential vulnerabilities) require careful planning rather than immediate action.

Distinguishing this point is crucial. Misunderstandings can distort cost-benefit analyses, causing teams to overlook more pressing security risks such as software vulnerabilities.

The real challenge in successfully transitioning to post-quantum cryptography lies in aligning the urgency of action with the actual threats. The following will clarify common misconceptions about the quantum threat to cryptography, covering encryption, signatures, and zero-knowledge proofs, with a particular focus on their implications for blockchain.

Timeline: How far are we from quantum computers that can crack encryption?

Despite the abundance of exaggerated claims, the likelihood of "cryptography-relevant quantum computers" emerging in the 2020s is extremely low.

By "cryptography-relevant quantum computers," I mean a fault-tolerant, error-corrected quantum computer capable of running Shor's algorithm at a scale sufficient to break elliptic curve cryptography (like secp256k1) or RSA (like RSA-2048) within a reasonable timeframe (e.g., continuous computation not exceeding one month).

Based on publicly available technical milestones and resource assessments, we are still very far from such a computer. While some companies claim that it may be achievable by 2030 or even 2035, known progress does not support these assertions.

Currently, whether it be trapped ions, superconducting qubits, or neutral atom systems, there is no quantum computing platform close to the hundreds of thousands or even millions of physical qubits required to crack RSA-2048 or secp256k1 (the exact number depends on error rates and error correction schemes).

The bottleneck is not only the number of qubits but also gate fidelity, connectivity between qubits, and the depth of error-correcting circuits required to run deep quantum algorithms. Some current systems have exceeded 1000 physical qubits, but this number alone is misleading: they lack the connectivity and fidelity needed for cryptographic computations.

Recent systems are approaching the physical error rate thresholds required for quantum error correction, but no one has yet been able to stably operate more than a few logical qubits, let alone the thousands of high-fidelity, deep-circuit, fault-tolerant logical qubits needed to run Shor's algorithm. The gap from proof of principle to the scale required for cryptanalysis remains vast.

In short: Cryptography-relevant quantum computers are out of reach until the number and fidelity of qubits improve by several orders of magnitude.

However, corporate press releases and media reports often create confusion. The main points of confusion include:

  1. "Quantum advantage" demonstrations: The tasks currently demonstrated are often carefully designed and not practically useful, simply because they can run on existing hardware and "appear" fast. This is often downplayed in promotions.
  2. Promotion of "thousands of physical qubits": This usually refers to quantum annealers, not gate-model quantum computers capable of running Shor's algorithm needed to attack public key cryptography.
  3. Misuse of "logical qubits": Physical qubits are noisy, and practical algorithms require "logical qubits" composed of many physical qubits through error correction. Running Shor's algorithm requires thousands of such logical qubits, each typically needing hundreds to thousands of physical qubits. However, some companies exaggerate, such as a recent claim of achieving 48 logical qubits with only 2 physical qubits per logical qubit using a "distance -2" error-correcting code (which can only detect errors, not correct them), which is meaningless.
  4. Misleading roadmaps: Many roadmaps' "logical qubits" only support "Clifford operations," which can be efficiently simulated by classical computers and are insufficient to run Shor's algorithm, which requires a large number of "non-Clifford gates" (like T gates). Therefore, even if a roadmap claims "thousands of logical qubits in X years," it does not mean that the company expects to be able to crack classical encryption by then.

These practices severely distort public (including seasoned observers) perceptions of quantum computing progress.

Of course, progress is indeed exciting. For example, Scott Aaronson recently wrote that given the "incredibly fast pace of hardware progress," he believes "it is a real possibility that we will have a fault-tolerant quantum computer capable of running Shor's algorithm before the next U.S. presidential election." However, he later clarified that this does not refer to cryptography-relevant quantum computers—he considers it a commitment even if it only involves fault-tolerantly factoring 15=3×5 (which is faster with pen and paper). This remains a small-scale demonstration, and such experiments always target 15 because modular arithmetic with 15 is simple, while slightly larger numbers (like 21) are much more difficult.

Key Conclusion: The expectation of a cryptography-relevant quantum computer capable of cracking RSA-2048 or secp256k1 within the next 5 years—critical for practical cryptography—lacks support from public progress. Even a 10-year timeline remains ambitious.

Thus, the excitement about progress does not contradict the assessment that "it will still take a decade or more."

So, what about the U.S. government's deadline of 2035 for a comprehensive post-quantum migration of government systems? I believe this is a reasonable timeline for completing a large-scale transition, but it does not predict that a cryptography-relevant quantum computer will necessarily emerge by then.

"Steal now, decrypt later" attacks: Who does it apply to? Who does it not apply to?

"Steal now, decrypt later" attacks refer to: attackers storing encrypted traffic now, waiting to decrypt it once cryptography-relevant quantum computers become available in the future. Nation-state adversaries are likely already archiving a significant amount of encrypted communications from the U.S. government for future decryption.

Therefore, encryption must be upgraded immediately, at least for data that requires confidentiality for 10-50 years or more.

However, digital signatures (the cornerstone of all blockchains) are different from encryption: they do not have the confidentiality that requires retrospective attacks. Even if quantum computers emerge in the future, they can only forge signatures from that point onward, not "decrypt" past signatures. As long as you can prove that the signature was generated before the emergence of quantum computers, it cannot be forged.

This makes the transition to post-quantum digital signatures far less urgent than the transition to encryption.

Mainstream platforms are doing just that:

  • Chrome and Cloudflare have deployed a hybrid X25519+ML-KEM scheme for web TLS encryption. "Hybrid" means using both a post-quantum secure scheme (ML-KEM) and an existing scheme (X25519), combining the security of both to defend against HNDL attacks while retaining classical security in case the post-quantum scheme fails.
  • Apple's iMessage (PQ3 protocol) and Signal (PQXDH and SPQR protocols) have also deployed similar hybrid post-quantum encryption.

In contrast, the deployment of post-quantum digital signatures on critical network infrastructure has been delayed until cryptography-relevant quantum computers are truly imminent. This is because current post-quantum signature schemes would lead to performance degradation (as detailed below).

The situation for zero-knowledge proofs (zkSNARKs) is similar to that of signatures. Even those non-post-quantum secure zkSNARKs (which use elliptic curve cryptography) have their "zero-knowledge" property itself being post-quantum secure. This property ensures that the proof does not leak any information about the secret (which quantum computers cannot exploit), so there is no confidential information to "steal now" for future decryption. Therefore, zkSNARKs are also not easily susceptible to HNDL attacks. Any zkSNARK proof generated before the emergence of quantum computers is trustworthy (even if it uses elliptic curve cryptography), and only after quantum computers emerge can attackers forge false proofs.

What does this mean for blockchain?

Most blockchains are not easily susceptible to HNDL attacks.

Non-privacy chains like current Bitcoin and Ethereum primarily use non-post-quantum cryptography for transaction authorization (i.e., digital signatures), not encryption. These signatures do not pose HNDL risks. For example, the Bitcoin blockchain is public, and the quantum threat lies in signature forgery (theft of funds), not in decrypting publicly available transaction data. This eliminates the immediate cryptographic urgency from HNDL.

Unfortunately, even analyses from authoritative institutions like the Federal Reserve have mistakenly claimed that Bitcoin is vulnerable to HNDL attacks, exaggerating the urgency of the transition.

Of course, a reduced urgency does not mean Bitcoin can rest easy. It faces different time pressures from the significant social coordination required for protocol changes (as detailed below).

The current exception is privacy chains. Many privacy chains encrypt or hide the recipient and amount. This confidential information can be stolen now and traced back to anonymize once quantum computers crack elliptic curve cryptography in the future. The severity of the attack varies by design (for example, Monero's ring signatures and key images may allow the transaction graph to be fully reconstructed). Therefore, if users care about their transactions not being exposed by future quantum computers, privacy chains should transition to post-quantum primitives (or hybrid schemes) as soon as possible or adopt architectures that do not put decryptable secrets on-chain.

Bitcoin's unique challenges: Governance deadlock and "sleeping coins"

For Bitcoin, two real factors drive the urgency to start planning for post-quantum signatures, both unrelated to quantum technology itself:

  • Slow governance: Bitcoin changes slowly, and any controversy can lead to destructive hard forks.
  • Inability to migrate passively: Coin owners must actively migrate their coins. This means that abandoned, quantum-vulnerable coins cannot be protected. It is estimated that such "sleeping" and quantum-vulnerable BTC could reach millions, currently worth tens of billions of dollars.

However, the quantum threat to Bitcoin is not an "overnight" apocalypse; it resembles a selective, gradual target-locking process. Early quantum attacks will be extremely costly and slow, with attackers selectively targeting high-value wallets.

Moreover, users who avoid address reuse and do not use Taproot addresses (the latter directly expose public keys on-chain) are relatively safe even without a protocol upgrade—since their public keys remain hidden behind hash values until a spending transaction is broadcast. Only when the spending transaction is broadcast does the public key become exposed, at which point there will be a brief real-time race: honest users will try to confirm the transaction as quickly as possible, while quantum attackers will attempt to compute the private key and steal the coins before that.

Thus, the truly vulnerable coins are those whose public keys have already been exposed: early P2PK outputs, reused addresses, and assets held in Taproot.

For abandoned vulnerable coins, the solutions are tricky: either the community agrees on a "cut-off date," after which un-migrated coins are considered destroyed; or they allow them to be seized by future owners of quantum computers. The latter would bring serious legal and security issues.

The final unique challenge for Bitcoin is its low transaction throughput. Even if a migration plan is finalized, migrating all vulnerable funds at the current rate would take months.

These challenges necessitate that Bitcoin begin planning for a post-quantum transition now—not because quantum computers may emerge before 2030, but because the governance, coordination, and technical logistics required to migrate assets worth hundreds of billions of dollars will take years in itself.

The quantum threat to Bitcoin is real, but the time pressure mainly stems from its own constraints rather than the imminent arrival of quantum computers.

Note: The vulnerabilities regarding signatures mentioned above do not affect Bitcoin's economic security (i.e., proof-of-work consensus). PoW relies on hash operations, which are only affected by the quadratic speedup of Grover's search algorithm, and the actual overhead is significant, making substantial acceleration unlikely. Even if it were possible, it would only advantage large miners rather than disrupt its economic security model.

The Costs and Risks of Post-Quantum Signatures

Why shouldn't blockchains hastily deploy post-quantum signatures? We need to understand their performance costs and our confidence in these new schemes, which are still evolving.

Post-quantum cryptography is primarily based on five types of mathematical problems: hashing, coding, lattices, multivariate quadratic equations, and elliptic curve isogenies. The diversity arises because the efficiency of schemes is related to the "structural" nature of the problems they rely on: the more structure, the higher the efficiency, but it may also leave more openings for attack algorithms, which is a fundamental trade-off.

  • Hash-based schemes are the most conservative (with the highest confidence in security) but have the worst performance. For example, NIST standardized hash signatures are at least 7-8KB, while current elliptic curve signatures are only 64 bytes, a difference of about a hundred times.
  • Lattice-based schemes are the current focus of deployment. The only post-quantum encryption scheme selected by NIST (ML-KEM) and two of the three signature schemes (ML-DSA, Falcon) are based on lattices.
  • The size of ML-DSA signatures is about 2.4-4.6KB, which is 40-70 times larger than current signatures.
  • Falcon signatures are smaller (0.7-1.3KB) but are extremely complex to implement, involving constant-time floating-point operations, with successful cases of side-channel attacks already reported. One of its founders described it as "the most complex cryptographic algorithm I have ever implemented."
  • The implementation security challenges are greater: lattice-based signatures have more sensitive intermediate values and complex rejection sampling logic than elliptic curve signatures, requiring stronger side-channel and fault injection protections.

The direct risks posed by these issues are far more immediate than the distant reality of quantum computers.

Historical lessons also remind us to remain cautious: leading candidates in the NIST standardization process, such as Rainbow (MQ-based signatures) and SIKE/SIDH (isogeny-based encryption), have been broken by classical computers. This illustrates the risks of premature standardization and deployment.

The internet infrastructure has taken a cautious approach to signature migration, which is particularly noteworthy given that cryptographic transitions are inherently time-consuming (for example, the migration from MD5/SHA-1 has taken years and is still not fully complete).

Unique Challenges of Blockchain vs. Internet Infrastructure

On the positive side, blockchains maintained by open-source communities (like Ethereum and Solana) can upgrade faster than traditional network infrastructure. On the downside, traditional networks can reduce their attack surface through frequent key rotations, while the coins and associated keys on blockchains may be exposed for long periods.

Overall, blockchains should still emulate the cautious signature migration strategies of networks. Both are not susceptible to HNDL attacks in their signatures, and the costs and risks of premature migration are significant.

Blockchains also have unique complexities that make premature migration particularly dangerous:

  • Signature aggregation requirements: Blockchains often need to quickly aggregate a large number of signatures (like BLS signatures). While BLS is fast, it is not post-quantum secure. Research on post-quantum signature aggregation based on SNARKs shows promise but is still in its early stages.
  • The future of SNARKs: The community currently favors hash-based post-quantum SNARKs, but I believe that in the coming months to years, lattice-based SNARK alternatives will emerge, which will perform better in various aspects (like proof length).

The more pressing issue currently is: implementation security.

For many years to come, implementation vulnerabilities will pose a greater security risk than quantum computers. For SNARKs, the main threat is software vulnerabilities. Digital signatures and encryption already face challenges, while SNARKs are much more complex. In fact, digital signatures can be viewed as a very simplified form of zkSNARK.

For post-quantum signatures, implementation attacks such as side-channel and fault injection are more urgent threats. The community will need years to fortify these implementations.

Therefore, transitioning too early before the dust settles may lock us into suboptimal solutions or force a second migration to fix vulnerabilities.

What Should We Do? Seven Recommendations

Based on the realities outlined above, I offer the following recommendations to all parties (from builders to decision-makers). The overarching principle is: take the quantum threat seriously, but do not assume that cryptography-relevant quantum computers will emerge before 2030 (current progress does not support this assumption). At the same time, there are things we can and should do now:

  1. Immediately deploy hybrid encryption: at least in areas where long-term confidentiality is needed and costs are acceptable. Many browsers, CDNs, and communication applications (like iMessage and Signal) have begun deploying this. Hybrid schemes (post-quantum + classical) can defend against HNDL attacks and mitigate potential weaknesses of post-quantum schemes.
  2. Use hash-based signatures immediately in scenarios where larger sizes can be tolerated: for example, in low-frequency, size-insensitive scenarios like software/firmware updates, hybrid hash signatures can be adopted now (the hybrid approach is to hedge against implementation vulnerabilities of new schemes). This provides a conservative "lifeboat" in case quantum computers unexpectedly appear sooner.
  3. Blockchains do not need to rush into post-quantum signatures, but they should start planning immediately:
  4. Developers should emulate the cautious attitude of the network PKI community to mature the schemes.
  5. Public chains like Bitcoin need to define migration paths and policies for "sleeping" vulnerable funds. Bitcoin, in particular, needs to start planning now, as its challenges are mainly non-technical (slow governance, many high-value "sleeping" addresses).
  6. Allow time for the maturation of post-quantum SNARKs and aggregatable signatures (which may take several years) to avoid prematurely locking into suboptimal solutions.
  7. Regarding Ethereum accounts: smart contract wallets (which can be upgraded) may provide a smoother migration path, but the difference is limited. More important than account types is that the community continues to advance research on post-quantum primitives and contingency plans. A broader design insight: decoupling account identity from specific signature schemes (like account abstraction) can provide greater flexibility, benefiting not only post-quantum migration but also supporting sponsored transactions, social recovery, and other features.
  8. Privacy chains should prioritize transitioning (if performance is acceptable): their users' confidentiality is currently exposed to HNDL attacks. Consider hybrid schemes or architectural adjustments to avoid putting decryptable secrets on-chain.
  9. In the short term, prioritize implementation security over excessive focus on quantum threats: for complex cryptography like SNARKs and post-quantum signatures, vulnerabilities and implementation attacks will pose a greater risk than quantum computers for many years to come. Invest now in auditing, fuzz testing, formal verification, and defense in depth; do not let quantum anxiety overshadow more urgent vulnerability threats.
  10. Continue funding quantum computing research and development: from a national security perspective, it is essential to maintain funding and talent development. If major adversaries gain cryptography-relevant quantum computing capabilities first, it will pose a serious risk.
  11. Maintain a rational perspective on quantum computing news: more milestones will emerge in the future. However, each milestone precisely demonstrates how far we are from the goal. Treat press releases as progress reports that require critical evaluation, not as signals for hasty action.

Of course, technological breakthroughs may accelerate, and bottlenecks may extend predictions. I am not asserting that it is impossible within five years; I just believe the likelihood is very low. Following the above recommendations can help us avoid more direct and likely risks: implementation vulnerabilities, hasty deployments, and common mistakes in cryptographic transitions.

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink