The main worry about quantum computing is that it will make public-key encrypted materials readable. The truth is narrower and more useful: the cipher protecting your data will likely be fine. What actually breaks is the math underneath public-key cryptography, the moment two parties agree on a key, and the moment a signature is trusted as genuine. That changes both what you have to protect (key exchanges and signing infrastructure, not bulk data encryption) and how soon (harvested traffic today is already at risk, even though the break is years away).
Modern cryptography is not one technology. It combines layers that protect data with layers that establish trust and move keys around, and quantum computing reaches only the second. Symmetric encryption, which does the bulk of the protecting, stays sound when implemented with sufficiently strong key sizes, while public-key cryptography, which sets up every secure session, does not. Seen that way, migration is a targeted problem rather than a wholesale replacement, and its deadline is set less by when a quantum computer arrives than by how long today's intercepted data needs to stay secret.
This article covers why the two layers diverge under quantum attack, and why your migration deadline comes from your data's shelf life, not a calendar entry on your quantum roadmap.
Two Kinds of Cryptography: Symmetric and Public-Key
When people say "encryption," they mean one thing. Secure communication actually depends on two.
Symmetric encryption uses a single shared key to encrypt and decrypt. Because both parties hold the same key, it is fast and efficient, the standard choice for protecting large volumes of data. AES (Advanced Encryption Standard) and ChaCha20 are common examples, used for files, databases, backups, VPN traffic, and application data.
The difficulty with symmetric encryption has never been protecting the data. It's getting the shared key to the other party securely and proving who you're actually talking to. Those are the two problems public-key cryptography solves.
Public-key cryptography uses two mathematically linked keys instead of one: a public key anyone can hold, and a private key that stays secret. Two parties who have never met can use this to exchange a shared key securely, and to prove, via digital signatures, that a message or identity is genuine.
Encryption is like a night deposit box: anyone can drop something in through the slot, but only the key holder can take it back out. A signature flips that around, only the sender can produce it, but anyone can check it's real. One lets strangers send you secrets; the other lets them trust what you send back.
| Symmetric encryption | Public-key cryptography | |
|---|---|---|
| Keys | One shared secret key | Public and private key pair |
| Role | Protects data | Establishes trust and exchanges keys |
| Performance | Fast and efficient | Computationally heavier |
| Examples | AES, ChaCha20 | RSA, ECC, Diffie-Hellman |
| Used for | Files, databases, VPN traffic | Certificates, TLS, authentication, signatures |
What Quantum Computing Threatens: Shor and Grover
Quantum computers are not faster versions of today's machines. They solve certain mathematical problems in a different way, and that difference, traceable to two specific algorithms, is why their effect on cryptography is uneven.
Shor's algorithm, published by Peter Shor in 1994, could efficiently solve the problems today's public-key cryptography depends on: integer factorization, which underpins RSA, and the discrete logarithm problem, which underpins ECC and Diffie-Hellman. Both the deposit box's lock and the signature's unforgeable mark rely on the same premise, that certain math problems are too hard to work backward from. Shor's algorithm removes that premise entirely. A capable quantum computer running it doesn't just make the lock harder to pick; it makes "hard to pick" stop being true. Grover's algorithm, introduced by Lov Grover in 1996, is far more limited. It does not touch the mathematics behind an algorithm. It speeds up brute-force search for a key, with at most a quadratic improvement over classical search. That's a real gain, but nothing like Shor's advantage, and it's the reason symmetric encryption, the kind doing the actual sealing in the deposit box, stays sound. It just needs a longer key.
The distinction is the difference between finding a master key and searching faster. Shor's algorithm is a master key for an entire class of locks. Grover's algorithm only lets you try keys more quickly, and there are still an enormous number to try.
Why Symmetric Encryption Survives
The security of symmetric encryption does not rest on a mathematical problem a quantum computer could solve more efficiently. It rests on the size of the key space. Without the key, the only route to the data is to try every combination, and AES offers no structure for an algorithm to exploit as a shortcut.
Grover's algorithm gives at most a quadratic speedup for that search. In theory it halves the effective key length, so AES-128 would offer about 64 bits of security against quantum search and AES-256 about 128 bits. In practice, the reduction is smaller, because Grover's search is sequential and does not parallelize efficiently. AES-256 is a sound choice for long-term confidentiality, and the response to Grover is to prefer larger symmetric keys, not to replace the algorithm.
Hash functions behave the same way. SHA-256, SHA-384, SHA-512, and SHA-3 lose some effective security under Grover's algorithm but are not broken, and a larger output size restores the margin.
Why RSA and ECC Do Not
RSA and ECC rest on different grounds. Their security comes from problems believed infeasible for classical computers within any practical timeframe. RSA relies on integer factorization: multiplying into two large primes is easy but recovering them from the product becomes prohibitively hard as the numbers grow. ECC and Diffie-Hellman rely on the discrete logarithm problem, which classical computers also cannot solve efficiently.
Shor's algorithm removes that assumption. A capable quantum computer could solve both factorization and discrete logarithms efficiently, taking away the foundation these algorithms stand on. That is a collapse of the assumption that made them trustworthy, not a gradual weakening.
This is what makes the timing hard. RSA and ECC do not decay in a way you can watch and respond to. They hold until a capable machine exists, and then they do not, with no slow decline to react to along the way. The decision to migrate cannot wait for a warning sign, because there will not be one.
The immediate consequence is specific. The data protected by AES does not become readable, but the trust mechanisms around it fail: certificates could be forged, key exchange intercepted, and digital signatures would no longer prove authenticity. The deposit box's lock and the signature's unforgeable mark were never separate problems — both depended on the same premise, and Shor's algorithm removes that premise from both at once. The box may still hold whatever's dropped in it, but an attacker who can forge both the lock's key and the signature can now walk up, present a counterfeit key, and be trusted as the one who's supposed to open it.
NIST ran a multi-year effort to standardize post-quantum algorithms for this reason. The aim was to replace the public-key algorithms whose assumptions no longer hold against a future quantum computer, and to leave the rest of the stack intact.
The Key Exchange Problem: Why Migration Still Matters
Symmetric encryption stays secure, so the reason for migrating lies in how secure sessions are set up.
When you connect to a website, application, or VPN, symmetric encryption is not used first. Both sides have to agree on a shared key before any data is exchanged, and today that step relies on public-key cryptography. A TLS connection runs roughly like this:
- Your device connects to a server.
- The server presents its certificate to prove its identity.
- Your device verifies that the certificate is genuine.
- Public-key cryptography, typically RSA or ECC today and an algorithm such as ML-KEM in post-quantum deployments, establishes a shared session key.
- AES encrypts the rest of the communication using that key.
Quantum computing threatens steps two and four, not step five. An attacker who could forge the server's certificate or break the public-key cryptography used in the handshake would be able to impersonate the server or derive the same session key both parties agreed on, with no need to attack AES because they would already hold the legitimate key.
This is the basis of harvest-now, decrypt-later (HNDL) exposure. Encrypted traffic can be recorded and stored today, and if the public-key cryptography that protected its key exchange is broken later, that stored traffic can then be decrypted. The exposure is greatest for data with a long confidentiality lifetime, information that must stay protected for longer than today's public-key cryptography can be relied on.
The deposit box makes the relationship clear. AES is the lock protecting what's inside, and public-key cryptography is the moment you and the bank agree on a combination before anything gets dropped in. However strong the lock, it doesn't matter if someone intercepts that agreement and gets the combination for themselves. This is why migration targets public-key algorithms and keeps symmetric encryption.
The Deadline Is Set by Your Data, Not by the Machine
A quantum computer that can break today's public-key algorithms does not exist yet, and that is exactly why an arrival date makes a poor planning tool. No one can commit to one, and as public-key cryptography gives no gradual warning before it goes, waiting for a signal is not a strategy.
A more reliable clock is your own. Take how long a class of data must stay confidential and add how long its migration will take. If that total runs past the point where the public-key cryptography protecting it can still be trusted, the work needs to be underway. For records that must stay private for ten or twenty years, that threshold is already close.
This is why governments, NIST, and industry point organizations toward migration planning now. The migration is long, and the deadline is set by data that already exists, so neither waits on a working quantum computer.
What Post-Quantum Migration Replaces, and What Stays
A common misconception is that migration means replacing every cryptographic algorithm in use. The scope is narrower than that.
The focus is on the public-key layer: RSA, ECC, classical key exchange, and traditional signature algorithms. These are being succeeded by post-quantum algorithms such as ML-KEM for key establishment and ML-DSA for digital signatures, standardized by NIST as FIPS 203 and FIPS 204. Symmetric cryptography keeps its role, with AES and hash functions including SHA-2 and SHA-3 remaining core building blocks.
For most organizations, this will not happen at once. Deployments are expected to follow a dual-stack approach, where classical and post-quantum cryptography are used together during the migration period. This strengthens security by ensuring protection against both classical and future quantum threats while organizations transition to quantum-resistant algorithms.
The Point
"Quantum will break encryption" misleads more than it informs. It points at the data, when the exposure is in the handshake, and it points at a future machine, when the deadline is set by data you are already storing. Build the cryptographic inventory, migrate the public-key layer before your longest-lived data outlives it, and the quantum timeline becomes something you plan around rather than wait on.
Cryptography is embedded across the environment: in applications, VPNs, certificates, APIs, databases, operating systems, cloud workloads, firmware, IoT devices, hardware, and third-party libraries. Much of it has built up over years, is poorly documented, and is owned by different teams. Without a complete inventory, an organization cannot assess where vulnerable algorithms run, decide what to prioritize, identify systems that cannot be upgraded, or size the migration.
The UAE cryptography regulation reflects this, requiring organizations to understand their cryptographic environment before developing a migration plan. Discovery provides the visibility to make those decisions and to build a phased roadmap.
QuantumGate's Crypto Discovery Tool is built to provide that inventory, a starting point for organizations building their migration roadmap.