The Asymmetry in Quantum Threats

Summary

In a boardroom, someone says, “Our AES encryption is already strong, so quantum can wait.” It sounds reasonable, but it misreads the quantum threat. If you’ve nodded along, you’re not alone.

AES isn’t the weak link. Shor’s algorithm breaks the public-key cryptography used to set up AES keys and the digital signatures that verify identities; once that setup breaks, the AES keys it produced are exposed. Grover’s algorithm gives a narrower advantage against AES, largely mitigated by using a longer key.

That is the asymmetry, and it is why doubling your AES key, prudent as it is, does not make you quantum-ready. Timing is the other half. Attackers can record traffic today and decrypt it years from now. Systems must stop trusting breakable signatures before an attacker can forge them.

In this paper, I explain the mechanics, frame Mosca’s inequality as a timing tool, and offer five concrete moves for technology leaders. The aim: to help you weigh priorities, distinguish what quantum computers could break from what remains secure, identify dependencies, and see why timing matters.

What prompted me to write this paper

Conversations with senior leaders at global organisations have prompted me to consider how we make the case for quantum readiness. They often ask: “If we already use strong AES encryption, why act now?” It is a fair question: symmetric encryption and public-key cryptography face different quantum threats.

As a senior instructor at Quantum Academy, I am privileged to work with its founder, Marin Ivezic, who has a rare gift for keeping pace with this fast-moving field, and for turning that pace into a steady stream of careful writing across public forums. He sets the bar I aim at. In his recent post [1], he unpacks exactly this question.

I see these conversations as an opportunity to clarify distinctions. AES may remain strong while public-key mechanisms that establish or protect its keys become vulnerable. Longer AES keys better resist key searches, but do not address weaknesses elsewhere in the system.

If this topic supports your role or your team’s development, explore Quantum Academy’s courses and certifications [3], including introductory options and learning paths for leaders and practitioners preparing to guide or implement quantum-readiness programmes.

For arguments on timing pressure and digital-currency rails, see my earlier pieces, Year 2029: How Google’s Quantum Warning (Q-Day) Came True and From Cryptos to Quantum: The Great Financial Convergence, also listed under Related insights below.

Note: A glossary in the Appendix defines technical terms like AES, TLS, X25519, RSA, Shor’s, and Grover’s. Consult it whenever a term is unfamiliar.

1. How a secure connection with your bank works

When you log in to your bank, your browser and the bank’s server perform three tasks in a fraction of a second: establish a shared secret, verify the bank’s identity, and protect subsequent messages. Each task uses a different key.

Symmetric encryption uses one shared key to encrypt and decrypt messages. AES (Advanced Encryption Standard) (NIST FIPS 197), first published in November 2001 and reissued with editorial corrections in May 2023, is a widely used, government-approved block cipher. It encrypts electronic data and is the most commonly used symmetric method.

Public-key cryptography handles the other tasks using two related keys: a shareable public key and a secret private key. This walkthrough below uses TLS 1.3 [4], the protocol behind modern HTTPS.

Step 1. Both sides create temporary key pairs

Your browser generates a short-lived public/private key pair and sends the public key to the bank, which returns its own. Each side keeps its private key. Anyone monitoring the connection can see the public keys; security depends on private keys staying on each machine and being mathematically impossible to derive from the transmitted data.

Step 2. Both sides calculate the same shared secret

Your browser combines its private key with the bank’s public key; the bank combines its private key with your browser’s public key. Both calculations produce the same shared secret, which neither side sends over the internet. This example uses X25519, an elliptic-curve Diffie–Hellman scheme [5]. It establishes a secret but does not encrypt data.

Step 3. They turn the secret into working keys

Both sides feed the shared secret and connection details into a key-derivation function, producing working keys: one set protects the remaining setup, while separate keys protect messages in each direction. The channel is encrypted, but it hasn’t been authenticated as belonging to the bank. Encrypted chat may still be with an impostor.

Step 4. The bank proves it is the bank

The bank has a long-lived signing key pair and a digital certificate linking its public key to its website identity. During setup, it sends the certificate and signs a handshake summary with its private key. Your browser checks the certificate and verifies the signature using the public key, binding the bank’s identity to this conversation.

A digital signature is not a scanned handwritten signature or simply “encryption with a private key”. It is a mathematical fingerprint of the exact signed information, created with the sender’s private key and verifiable with the matching public key. Changing even one character invalidates the fingerprint.

Step 5. They finish the checks and start protecting your messages

Each side sends a cryptographic “Finished” message proving the handshake is intact, and both derive the same secret. After verification, handshake keys are retired, and session keys protect banking messages. In TLS 1.3, these are application traffic keys; with AES, separate keys protect browser-to-bank and bank-to-browser messages.

For ordinary consumer banking, only the bank presents a TLS certificate. Your browser presents no signed certificate; instead, you identify yourself after the connection is established with your login, password, passkey, or other bank credentials.

Why the distinction matters for quantum risk

One connection uses three distinct key roles: a temporary key-agreement pair establishes the secret, the bank’s signing pair authenticates the exchange, and symmetric AES keys protect messages.

The signing key does not generate the AES key, and a longer AES key does not strengthen key agreement or signatures. Assess each role separately for quantum risk.

2. Two quantum algorithms, two different threats

Two well-known quantum algorithms threaten different parts of cryptography, so saying “but AES is strong” misses the point.

Shor’s algorithm. The one that breaks public-key maths.

In 1994, Peter Shor showed that quantum computers could efficiently factor large numbers and solve discrete logarithms. Conventional public-key cryptography relies on these problems being practically unsolvable: RSA uses factoring, while Diffie–Hellman and conventional elliptic-curve methods use discrete logarithms.

A sufficiently large, reliable quantum computer running Shor’s algorithm could derive a private key from its public key, compromising both encryption-key agreement and digital signatures used for authentication. Such a machine is called a cryptographically relevant quantum computer (CRQC); when one will exist remains unknown.

Grover’s algorithm. The one that searches.

In 1996, Lov Grover introduced a quantum algorithm for searching unstructured possibilities [2]. Like finding the right key among unmarked ones, it narrows the search faster than testing each key.

Grover can search for an AES key among N possibilities in roughly √N attempts, a real advantage. But each attempt requires substantial quantum computation, and attempts cannot run in parallel within a single search.

Shor threatens the mathematics behind public-key cryptography; Grover offers a narrower advantage against symmetric encryption. Their reach differs. The reassurance “but AES is strong” conflates the threats: AES’s strength says nothing about public-key components Shor could compromise. That asymmetry drives migration pressure.

3. Key Length. Why doubling it does matter

In “quadratic speedup,” the square root applies to the number of possible keys, not bits. Each extra bit doubles the key space: 128 bits offers 2^128 options, while 256 bits offers 2^256, an increase by 2^128, or roughly 340 undecillion (3.4 × 10^38).

Under the simplified Grover model, the comparison looks like this

AES key length	Number of possible keys	Approximate Grover search iterations
128 bits	2^128	2^64
256 bits	2^256	2^128

These figures count search iterations, not time or total operating cost. AES-256 requires 2^64 times more search work than AES-128, about 18 quintillion. Grover’s rule is unchanged; it applies to a much larger space. In plain terms: doubling the key length changes how much work the rule produces.

The table also shows the usual round numbers for Grover’s algorithm (roughly $2^{64}$ and $2^{128}$ iterations). The more precise count is $\frac{\pi}{4}\sqrt{N}$. Because $\frac{\pi}{4}$ is about 0.785, roughly three-quarters, the exact number of iterations is a bit under those round figures. The difference does not change the comparison or the practical conclusions.

4. Why “halving the security bits” can be misleading

“Grover halves the security of AES” may be technically correct but practically misleading [2]. Attacking AES-128 would not cost the same as testing 2^64 keys on an ordinary computer: each Grover iteration requires substantial, reliable quantum computation and error correction, and iterations cannot be run in parallel within one search.

Multiple quantum computers help, but less than classical parallelism: a thousand ordinary machines offer a thousand-fold speed-up, while a thousand quantum machines provide only about 32-fold. Each added quantum machine yields diminishing returns. A theoretical advantage is not necessarily a practical attack.

Marin isn’t claiming AES-128 is about to break. AES-256 provides a conservative margin for long-lived sensitive data, but the main migration challenge remains public-key cryptography; it doesn’t replace migrating those components.

5. Why AES-256 does not make the whole system quantum-ready

This is where AES’s strength stops helping: longer keys make brute-force searches harder but cannot prevent attackers from recovering keys through weaknesses in their establishment.

For a bank using conventional X25519, a future attacker with a CRQC could break a recorded public exchange, reconstruct the shared secret, and derive the AES session key—whether it is 128 or 256 bits—without searching AES keys.

The same applies to stored data: break the RSA wrapping an AES-256 key, and the AES key is exposed. The issue is dependency: AES may remain strong while the public-key component protecting its key does not.

6. Harvest Now, Decrypt Later (HNDL)

An attacker doesn’t need a quantum computer today—only recorded encrypted traffic, including public handshake data. They can store it and decrypt it when a suitable quantum computer becomes available. This is harvest now, decrypt later (HNDL) [6].

In the X25519 example, the attacker uses the recorded public share to recover a private value, reconstruct the shared secret, derive the AES keys, and read the messages. AES itself remains uncompromised.

The information’s lifespan sets the deadline. Financial records, personal data, commercial negotiations, and other information requiring years of confidentiality are already at risk. Future upgrades cannot protect data recorded today.

Mosca’s inequality: a timing formula

Michele Mosca of the University of Waterloo formalised the timing problem as Mosca’s inequality [7]: if X is how long information must remain confidential, Y how long migration takes, and Z how long until a CRQC arrives, there’s a problem when X + Y > Z. With harvest-now, decrypt-later attacks, X starts when an attacker records your traffic, not when they decrypt it.

Why forward secrecy does not fix this

Forward secrecy assumes discarded temporary secrets can’t be reconstructed from public values exchanged over the wire. Elliptic-curve Diffie–Hellman makes deriving a private value from a public one intractable for ordinary computers, so stealing a long-term signing key alone doesn’t expose past sessions.

A sufficiently powerful quantum computer running Shor’s algorithm could recover private values from recorded public shares, reconstruct shared secrets, and read past sessions.

Forward secrecy remains useful, but it is not quantum-resistant.

7. Trust Now, Forge Later (TNFL)

Encryption protects confidentiality; digital signatures protect authenticity by letting verifiers confirm that a file, update, or message was signed with a particular private key and detect later changes.

This assurance depends on both a secure signature scheme and correctly linking its public key to the trusted person or organisation.

RSA, ECDSA, and EdDSA are widely used signature schemes, but a sufficiently powerful quantum computer running Shor’s algorithm would compromise all three. RFC 8032 provides the mathematical background for Ed-family signatures [8]; the Appendix glossary briefly describes each scheme.

Anyone who recovers a signing secret can forge signatures that verify under its public key. Depending on the key’s use, this could make malicious software, fraudulent documents, or an impersonated server appear genuine.

A precedent exists for a different cryptographic weakness. In January 2020, Gaëtan Leurent and Thomas Peyrin demonstrated the first practical chosen-prefix collision against SHA-1, branded “SHA-1 is a Shambles” [9]. Costing about US$45,000 in cloud computing, it included a forged PGP signature linked to a valid SHA-1 certificate in the PGP web of trust. The weakness was SHA-1, not RSA: the attack exploited a hash collision, not a signature-scheme flaw. Still, the lesson holds: weaken the primitive underpinning a signature, and forged artefacts can pass checks that trust the compromised scheme. With a future CRQC, Shor’s algorithm could undermine RSA and conventional elliptic-curve signatures as the SHA-1 collision did the PGP web of trust.

“Trust now, forge later” (TNFL) describes the danger of trusting a vulnerable public key after forgery becomes possible.

Unlike HNDL, it doesn’t involve collecting old signatures to forge later; the key question is whether the system still trusts the key when a CRQC appears. A future forgery won’t automatically alter securely stored documents, but reliable authenticity evidence must survive without relying solely on breakable signatures. Migrating signatures before forgery is practical, with trusted post-quantum keys and a safe transition in place.

8. Where TLS fits in all this

TLS (Transport Layer Security) holds the protocol together [4]. It defines how browsers and servers negotiate methods, establish secrets, authenticate connections, derive keys, and protect messages from reading or tampering. HTTPS is web traffic over TLS; TLS is a framework, not a single encryption algorithm.

TLS 1.3 removed weaker options, including RSA key transport, where browsers encrypted a secret with the server’s RSA public key. It instead uses temporary key agreement, providing forward secrecy if an attacker later steals the server’s signing key. TLS 1.3 also encrypts most of the handshake, reduces setup round trips, and requires encryption that prevents both reading and undetected alteration.

TLS 1.3 alone is not quantum resistant. Conventional X25519 key agreement remains vulnerable to sufficiently capable quantum computers. Post-quantum key agreement would not protect conventional RSA or elliptic-curve server signatures, which Shor’s algorithm can also break. These components must be migrated separately; replacing one does not secure the other.

TLS 1.3 supports post-quantum and hybrid key establishment. A well-designed hybrid combines conventional and post-quantum methods, ensuring the shared secret remains secure if either method remains secure. This approach is already being used in the real world.

9. What quantum readiness actually requires

The goal is not to replace all cryptography, but vulnerable public-key components while retaining adequately sized symmetric encryption and hash functions.

NIST’s first post-quantum standards (FIPS 203–205, finalised August 2024) [10] are

• ML-KEM for shared-secret establishment,
• ML-DSA for digital signatures, and
• hash-based SLH-DSA.

They run on ordinary computers; deployment requires no quantum computer.

For each critical system, ask: How are encryption keys established or protected? How are identities and signatures authenticated? How are working keys derived? What encrypts the data?

“AES-256” alone is not a cryptographic inventory. Migration timing should account for how long information must remain secret, how long signatures must be trusted, and how long migration will take. This calls for planned migration, not rushed, indiscriminate AES replacement.

10. From Awareness to Action

Understanding the two risks is only the start; turning it into migration is harder. Five moves separate organisations considering quantum readiness from those acting on it.

1. Build a cryptographic inventory. You cannot migrate what you cannot see. A Cryptography Bill of Materials (CBOM) [11] should list schemes and key sizes across TLS, code and document signing, firmware updates, email, archives, VPNs, HSMs and KMS. Record how long protected information must remain secret and signatures trusted. Only then can you assign real values to Y and X in Mosca’s inequality.
2. Design for crypto-agility. Build systems that can replace signature schemes or key-establishment methods without a rewrite, regardless of when a CRQC arrives. Hard-coded primitives are like hard-coded year fields. Agility costs less now than under pressure.
3. Track what is already shipping. Chrome defaults to hybrid X25519MLKEM768 for TLS; Apple’s iMessage PQ3 uses ML-KEM; Signal ships PQXDH [12]; and Cloudflare offers post-quantum TLS. These set real-world benchmarks for regulators, auditors and customers reviewing peers’ breach disclosures.
4. Tie migration to regulation and vendor roadmaps. The US National Security Agency’s CNSA 2.0 mandates migration for US national-security systems by 2035 [13], while the UK’s NCSC has published timelines [14]. The European Commission’s post-quantum migration roadmap [15] complements NIS2 and DORA, which strengthen cryptographic hygiene and operational resilience across the Union. Singapore’s Monetary Authority has issued financial-sector consultation guidance [16]. Regulatory requirements can unlock budgets. HSM, cloud, PKI, and software vendor roadmaps are also critical: engage vendors now and track gaps as findings.
5. Protect code signing and archives. TLS gets most attention, but signed firmware, CI/CD artefacts, S/MIME email, legal archives and regulatory submissions are harder because they rely on older, broader verifier ecosystems, and signatures may need to remain trustworthy long after a CRQC appears. TNFL applies here too, often with a longer Z tail in Mosca’s inequality.

For the board paper: Your exposure is regulatory, commercial and reputational. Customers, suppliers and regulators expect entrusted data to remain confidential and attributable for its stated lifetime. The ask isn’t “replace everything,” but “build the inventory, design for agility, start vendor conversations, and sequence migration to match the lifetimes of what we hold.”

11. Conclusion

Let me return to my opening question: If AES remains strong, why act on quantum now?

That’s good news: AES-256 provides a generous buffer against generic quantum search. But it doesn’t protect public-key components used to establish AES keys or authenticate parties, my main concern for long-lived systems.

Timing matters. Attackers can record traffic now and decrypt it later. For authenticity, systems must stop trusting signatures before attackers can forge them.

Neither complacency nor panic helps. Understand both risks, then plan a migration around your organisation’s information, systems and timelines. To reduce uncertainty, distinguish the threats and act first on the one that cannot wait.

Read Marin’s explanations and follow his work

Read Marin’s articles separately: first, his overview of public-key and symmetric cryptography [1] and system dependencies; then, his explanation of why Grover’s algorithm [2] doesn’t make practical attacks on AES possible. Also, follow him on X at @infosec [17] for commentary between articles.

To move from awareness to structured learning, explore Quantum Academy’s courses and professional certifications [3]. Choose a path suited to your role and organisation, whether you’re assessing business implications, leading a migration, or implementing technical changes.

Understanding the threat is the starting point; building response capability turns it into readiness.

Appendix. A short glossary

Name	Plain-English meaning	Main job
AES	Advanced Encryption Standard, standardised in 2001. A fast method using a shared secret key.	Encrypts the actual data.
Diffie–Hellman	A key-agreement approach published by Whitfield Diffie and Martin Hellman in 1976.	Lets two parties establish a shared secret without transmitting it.
ECC	Elliptic-Curve Cryptography, independently proposed by Neal Koblitz and Victor Miller in 1985. A family of techniques, not one specific algorithm.	Supports key agreement and signatures using relatively small conventional keys.
X25519	A particular elliptic-curve Diffie–Hellman method using Curve25519. The “25519” comes from the prime 2^255 − 19 used in its maths; the “X” is a naming convention for how the calculation is done, not a security property.	Establishes a shared secret.
RSA	A public-key system named after Rivest, Shamir and Adleman (1977). Security rests on the difficulty of factoring large numbers.	Supports encryption or signatures through separate schemes.
ECDSA	Elliptic Curve Digital Signature Algorithm. Elliptic-curve signatures proposed in the early 1990s.	Creates and verifies signatures.
EdDSA / Ed25519	Edwards-Curve Digital Signature Algorithm (2011), and Ed25519, its widely used version. Documented in RFC 8032 [8].	Creates and verifies signatures.
SHA-256	A hash function that produces a fixed-length fingerprint of data. It is not encryption.	Supports integrity checks and other cryptographic operations, including key derivation.
TLS	Transport Layer Security.	Coordinates authentication, key establishment, and protection of network traffic.
ML-KEM	A standardised post-quantum method for establishing shared secrets.	Protects key establishment against known classical and quantum attacks.
ML-DSA / SLH-DSA	Standardised post-quantum signature methods.	Protects authenticity against known classical and quantum attacks.

Why key lengths cannot be compared across schemes

A 256-bit AES key, 256-bit elliptic-curve key, and 2,048-bit RSA key aren’t equivalent: they use different mathematics and face different attacks, making key-size comparisons misleading.

AES keys can be lengthened to make Grover’s search harder. But for RSA and conventional elliptic curves, that won’t stop Shor’s algorithm. Longer RSA keys offer no meaningful quantum protection; the scheme must be replaced.

Sources for further reading

1. Marin Ivezic, “Public-Key and Symmetric Cryptography” (Quantum Academy / postquantum.com). Explains key establishment, authentication, derivation, and encryption.
2. Marin Ivezic, “How Grover’s Algorithm Works: The Honest Speedup” (postquantum.com). Explains quadratic search, AES key sizes, sequential execution, and attack limits.
3. Quantum Academy: Courses and Professional Certifications. Introductory courses, role-based paths, certifications, and team training in post-quantum security and quantum technologies.
4. RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”. Specification for the handshake, certificate verification, key derivation, and protocol improvements.
5. RFC 7748, “Elliptic Curves for Security”. Specifications for X25519, X448, and their use in key agreement.
6. CISA, NSA and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography” (Joint Cybersecurity Information factsheet, August 2023). Identifies Harvest Now, Decrypt Later (HNDL) as the migration risk and recommends early inventory and planning.
7. Mosca, M., “Cybersecurity in an Era with Quantum Computers: Will We Be Ready?” IACR Cryptology ePrint Archive 2015/1075 (2015); later published in IEEE Security & Privacy 16(5): 38–41 (Sept./Oct. 2018). Origin of Mosca’s inequality.
8. RFC 8032, “Edwards-Curve Digital Signature Algorithm (EdDSA)”. The specification for Ed25519 and Ed448 signatures.
9. Leurent, G., and Peyrin, T., “SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust” (USENIX Security 2020). Practical SHA-1 collision attack to forge a PGP signature in the web of trust.
10. NIST IR 8547, “Transition to Post-Quantum Cryptography Standards”. Quantum-vulnerable schemes and migration considerations.
11. OWASP CycloneDX, “Cryptography Bill of Materials (CBOM)”. Capabilities and schema for inventorying cryptographic assets (algorithms, keys, protocols, libraries) and software components.
12. Signal, “Quantum Resistance and the Signal Protocol: PQXDH” (Signal Foundation, September 2023). Signal’s post-quantum extended Diffie–Hellman key establishment, among the first production post-quantum key exchanges in a mainstream consumer service.
13. NSA, “NSA Releases Future Quantum-Resistant (QR) Algorithm Requirements for National Security Systems” (NSA press release, 7 September 2022; links to the CNSA 2.0 Cybersecurity Information Sheet and April 2024 FAQ). Establishes CNSA 2.0 and a 2035 migration deadline for US National Security Systems.
14. UK NCSC, “Timelines for migration to post-quantum cryptography”. The National Cyber Security Centre’s programme requires UK organisations to inventory vulnerable public-key cryptography and plan migration by 2028, completing the transition by 2035.
15. European Commission, “Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography” (C(2024) 2393, 11 April 2024). The EU-wide PQC roadmap coordinates Member State action with NIS2 and DORA on cryptographic hygiene and operational resilience.
16. Monetary Authority of Singapore, “Consultation Paper on Quantum-Safe Migration Guidance and Timelines for the Financial Sector” (2026). MAS’s proposed quantum-safe migration expectations for Singapore financial institutions: inventory, crypto-agility, and sequencing based on data lifetimes.
17. Marin Ivezic on X (@infosec). Running commentary on quantum, cybersecurity and frontier technology.

Related Grey Orbits insights

• Year 2029: How Google’s Quantum Warning (Q-Day) Came True, Triggering a Confidence Crisis — the migration pressure and timing argument.
• From Cryptos to Quantum: The Great Financial Convergence — how quantum readiness intersects with the digital currency rails.
• The Froth on the Frontiers: AI, Digital Currencies, Quantum — the broader frontier context across the three technologies.

About the Author

Viren Mantri is the founder of Grey Orbits in Singapore, Senior Instructor at Quantum Academy, and Executive Faculty at Singapore Management University Executive Development. Three decades across Standard Chartered, SC Ventures, UBS, McAfee, and KPMG inform his advisory work on AI, digital currencies, and quantum readiness. He authored the PETALS™ Framework for AI Governance, the Cybersecurity Model for Startups, and the Framework for Cyber Insurance.

© 2026 Viren Mantri, Grey Orbits. Licensed under a Creative Commons Attribution 4.0 International License.

Disclaimer: All views expressed here are entirely mine.