Post-Quantum Cryptography Explained: How Encryption Changes Before Quantum Computers Arrive

Public-key cryptography protects web connections, software updates, digital signatures, identity systems, financial records and countless machine-to-machine exchanges. Much of it relies on mathematical problems that are extremely difficult for ordinary computers but could be threatened by a sufficiently capable quantum computer. The exact date of such a machine is unknown. The migration problem is not.

Post-quantum cryptography, usually abbreviated PQC, is the field of designing classical cryptographic algorithms that are expected to resist attacks from both classical and quantum computers. It is not the same as putting a quantum device in a network, and it is not a promise that every future attack becomes impossible. It is a standards and engineering response to a changing threat model.

On August 13, 2024, the U.S. National Institute of Standards and Technology (NIST) published its first three finalized post-quantum encryption standards: ML-KEM for key establishment, ML-DSA for digital signatures and SLH-DSA as a hash-based signature standard. The difficult part now is discovering where vulnerable cryptography is embedded, selecting approved algorithms, updating protocols and validating systems that may stay in service for many years.

Direct answer: Post-quantum cryptography uses algorithms that run on ordinary computers but are designed to resist known quantum attacks against public-key systems. NIST's first finalized standards are ML-KEM, ML-DSA and SLH-DSA. PQC does not require a quantum computer and does not replace every form of encryption; it mainly addresses public-key key establishment and signatures. The immediate task is cryptographic inventory and staged migration, not waiting for a precise forecast of when quantum hardware will become powerful enough to break existing systems.

Why quantum computers change the cryptography discussion

Public-key cryptography uses hard mathematical problems

Public-key systems allow parties to communicate or verify signatures without first sharing a secret through a private channel. Different schemes rely on different mathematical assumptions. RSA relies on the difficulty of factoring large integers. Elliptic-curve systems rely on the difficulty of the discrete logarithm problem in an elliptic-curve group.

Think of a public-key lock as a padlock that anyone can snap shut but only the owner can open. The padlock's design is public. Its security rests on the fact that nobody knows a fast way to work backward from the closed lock to the key. With today's classical computers and properly chosen parameters, factoring and discrete logarithms are considered difficult enough for many applications. That statement is about current computational assumptions and implementation quality, not an eternal law. For a broader tour of how these pieces fit together, see our explainer on how encryption works.

Shor's algorithm is the central concern

A sufficiently large, fault-tolerant quantum computer could use Shor's algorithm, which the mathematician Peter Shor published in the mid-1990s, to solve integer factoring and discrete logarithm problems much faster than known classical methods. That is why RSA and elliptic-curve cryptography receive so much attention in post-quantum planning.

The phrase "sufficiently large" hides major engineering challenges. Quantum error correction, logical qubits (error-corrected qubits built from many noisy physical ones), reliable gates, memory, control systems and algorithms all matter. Our piece on how quantum computers actually work explains why a lab demonstration with dozens of qubits is a long way from a machine that attacks a 2,048-bit key.

The resource estimates keep moving, which is itself part of the story. In a paper posted to arXiv on May 21, 2025, Craig Gidney of Google Quantum AI estimated that a 2,048-bit RSA integer could be factored in less than a week by a quantum computer with fewer than one million noisy qubits. The earlier estimate, from Gidney and Martin Ekerå in 2019, had required about 20 million qubits, although it assumed a much shorter run time of roughly eight hours. The newer figure keeps the same physical assumptions, including a 0.1% gate error rate and a one-microsecond surface-code cycle. No machine of that size exists, and no one can responsibly turn an estimate like this into a calendar date. What the paper shows is that the cost of the attack on paper fell by more than an order of magnitude in six years.

Grover's algorithm has a different effect

Grover's algorithm offers a quadratic speedup for certain unstructured-search problems. It does not destroy symmetric encryption in the same way Shor's algorithm threatens public-key systems. NIST's draft transition document says that existing symmetric-key standards are less vulnerable to quantum attack and that NIST does not expect to need to transition away from them as part of the PQC migration. The usual response is to choose appropriate symmetric key sizes and review implementation details, while focusing PQC migration on public-key primitives and signatures.

The distinction matters because "quantum-safe encryption" is often used as if one replacement algorithm solves everything. Cryptography is a collection of primitives with different threat models, parameters and deployment roles.

Primitive	Typical job	Main quantum concern	Practical response
RSA	Key transport, signatures	Shor's algorithm	Replace with PQC standards
Elliptic-curve Diffie-Hellman (ECDH, X25519)	Key agreement	Shor's algorithm	Replace or hybridize with ML-KEM
ECDSA, EdDSA	Signatures	Shor's algorithm	Replace with ML-DSA, SLH-DSA or FN-DSA
AES	Bulk encryption	Grover's quadratic speedup	Keep, with adequate key size
SHA-2, SHA-3	Hashing	Grover and collision-search variants	Keep, with adequate output size

What post-quantum means

It is classical cryptography

PQC algorithms are intended to run on ordinary CPUs, servers, phones, browsers, embedded devices and hardware security modules. They do not require a quantum network or a quantum processor. That makes migration compatible with existing systems, although it can still require changes to protocols, certificates, libraries, firmware and hardware.

It is based on different assumptions

NIST's standardized algorithms use mathematical structures believed to resist both classical and quantum attacks. ML-KEM is based on structured lattice problems. ML-DSA also uses lattice-based constructions. SLH-DSA is based on hash functions. The security of any algorithm depends on the exact construction, parameter set, implementation and future cryptanalysis.

"Quantum-resistant" therefore means resistant to the best currently understood attacks under stated assumptions. It does not mean mathematically immune to every future idea.

It is not quantum cryptography

Quantum cryptography uses quantum physical effects in a communication protocol, while post-quantum cryptography uses classical algorithms designed for a quantum-threat environment. A company can deploy PQC without installing quantum hardware. Quantum key distribution, quantum random-number generation and PQC are related to quantum-security discussions but solve different engineering problems. Our explainer on the quantum internet covers the hardware-based side of that divide.

How lattice and hash-based schemes work, in plain terms

Lattices: finding a point in a fog of noise

A lattice is a regular grid of points that extends in many dimensions, like the intersections of a city street plan but with hundreds of directions instead of two. Lattice cryptography builds on the observation that certain questions about high-dimensional lattices, such as "which grid point is closest to this arbitrary spot," are hard to answer even when the grid is known. The hardness grows quickly as the number of dimensions rises.

ML-KEM's security rests on a problem in this family. NIST's FIPS 203 abstract says its security depends on the Module Learning with Errors problem. In everyday terms, the public key is a set of linear equations that has been deliberately blurred with small random errors. Anyone can use the blurred equations to hide a message, but only the holder of the secret that generated them can strip the noise away cleanly. Without the secret, recovering the answer means solving equations that are almost, but not exactly, correct, and no efficient classical or quantum algorithm for that is publicly known.

Hash-based signatures: a very large key ring

SLH-DSA takes a different route. Instead of leaning on algebraic structure, it leans only on the behavior of cryptographic hash functions, which turn any input into a fixed-length fingerprint that is infeasible to reverse. A hash-based signature scheme builds a large tree of one-time signing keys and publishes a single fingerprint of the whole tree as the public key. Each signature then reveals one leaf and the path of fingerprints connecting it to the top, so a verifier can check that the leaf belongs to the published tree.

The trade-off is size. The security assumption is conservative, because hash functions are among the best-studied tools in cryptography, but the signatures are long. That is why NIST describes SLH-DSA as a second signature standard built on a different mathematical approach, useful as a fallback if a flaw is ever found in the lattice-based ML-DSA.

NIST's first standardized algorithms

ML-KEM for key establishment

ML-KEM, standardized in FIPS 203 and derived from the CRYSTALS-Kyber submission, is a key-encapsulation mechanism. Two parties use it to establish a shared secret over a public channel. That shared secret can then support symmetric encryption for the actual data stream.

A KEM is not normally used to encrypt an entire video, database or email body directly. It establishes key material; a symmetric cipher handles bulk data. This separation is similar in spirit to how many current secure protocols use public-key operations to establish session keys and symmetric encryption for data.

FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, ordered from lowest to highest security strength and, correspondingly, from highest to lowest performance.

ML-DSA for signatures

ML-DSA, standardized in FIPS 204 and derived from CRYSTALS-Dilithium, is a digital-signature scheme. Signatures can support authenticity, integrity, software updates, certificates, document approval and non-repudiation designs, depending on the legal and operational context. For the everyday mechanics of signing a file, see how digital signatures prove a file is authentic.

Signature migration can affect certificate sizes, handshake messages, firmware storage, hardware accelerators and bandwidth. An organization must test not only whether a library implements the algorithm but whether all relying parties can process the resulting keys and signatures.

SLH-DSA for hash-based signatures

SLH-DSA, standardized in FIPS 205 and derived from SPHINCS+, is a stateless hash-based signature scheme. "Stateless" means the signer does not have to keep a counter of which one-time keys it has already used, which removes a class of operational mistakes that plague earlier stateful hash-based designs. Its performance and signature-size characteristics differ from lattice-based alternatives, so the choice is a system-design decision rather than a universal ranking.

FN-DSA and HQC: the next two

NIST's project page lists a fourth standard, FIPS 206, based on the Falcon submission and to be named FN-DSA. As of the page's August 5, 2026 update it is still in development. NIST also announced on March 11, 2025 that it had selected HQC as a fifth algorithm. HQC relies on error-correcting codes rather than lattices, so it is a hedge in case ML-KEM is found to be weak. NIST said at the time that a draft standard was expected in about a year, followed by a 90-day public comment period, with a final standard planned for 2027. HQC does not replace ML-KEM, which remains the recommended general-purpose choice.

How big the keys and signatures are

Size is the practical difference that engineers notice first. The table below uses the parameter-set sizes published by the Open Quantum Safe project's liboqs documentation, which implements the standardized algorithms.

Algorithm and parameter set	NIST security category	Public key (bytes)	Ciphertext or signature (bytes)
ML-KEM-512	1	800	768 (ciphertext)
ML-KEM-768	3	1,184	1,088 (ciphertext)
ML-KEM-1024	5	1,568	1,568 (ciphertext)
ML-DSA-44	2	1,312	2,420 (signature)
ML-DSA-65	3	1,952	3,309 (signature)
ML-DSA-87	5	2,592	4,627 (signature)
SLH-DSA-128s	1	32	7,856 (signature)
SLH-DSA-128f	1	32	17,088 (signature)
SLH-DSA-256f	5	64	49,856 (signature)

Sources: ML-KEM, ML-DSA and SLH-DSA pages, Open Quantum Safe. In the SLH-DSA names, "s" marks the small-signature variants and "f" the faster-signing ones.

The comparison with what these replace is stark. An elliptic-curve key exchange with X25519 uses 32-byte public values, and an Ed25519 signature is 64 bytes. Even the smallest ML-DSA signature in the table is roughly 38 times longer than that, and the largest SLH-DSA signature is nearly 800 times longer.

The cautionary tale of schemes that broke

Standardization was a public contest, and the contest had casualties. That history is the best reason for the caution about "quantum-resistant" labels.

In July 2022, Wouter Castryck and Thomas Decru of KU Leuven posted an attack on SIDH, the key-exchange scheme underneath the SIKE candidate. Their Magma implementation recovered keys for the parameter set aimed at NIST's first security level in about ten minutes on a single core. SIKE had advanced deep into NIST's multi-round process and had been widely regarded as secure. It fell to a classical computer, not a quantum one, using mathematics from the 1990s. Earlier the same year, Ward Beullens of IBM Research had broken Rainbow, a multivariate signature scheme that was one of three signature finalists, recovering a key in about 53 hours on a laptop.

The lesson is not that post-quantum cryptography is fragile. It is that new mathematical assumptions need years of public scrutiny, and that some candidates do not survive it. ML-KEM, ML-DSA and SLH-DSA came through multiple rounds of that scrutiny, but their lifetimes are measured in decades, so cryptographers keep attacking them. This is one reason NIST keeps backups such as HQC and SLH-DSA in the portfolio.

The harvest-now-decrypt-later problem

An adversary may collect encrypted traffic today and attempt to decrypt it in the future if the underlying public-key protection becomes vulnerable. This is often called harvest now, decrypt later. The risk is greatest for information that remains sensitive for a long time: government records, health data, trade secrets, identity information, long-lived credentials and archival communications.

The attacker does not need a quantum computer at the time of collection. The organization may believe that current encryption protects the data today, while the confidentiality lifetime of the data extends beyond the expected migration date. The exact risk depends on the data's value, retention, key exchange, storage and adversary capability.

This does not mean every encrypted message is already readable or that a quantum computer exists that can decrypt it. It means confidentiality planning should account for the time between collection, cryptographic migration and data expiration.

Notice the asymmetry between the two jobs of public-key cryptography. Confidentiality is retroactive: a recording made today can be attacked later. Authentication is not. A forged signature only helps an attacker at the moment someone relies on it, so a signature scheme can be replaced closer to the time the threat becomes real. That asymmetry explains why key exchange has been migrated first.

What deployment looks like so far

Hybrid key exchange has reached ordinary browsing

A hybrid design combines a classical and a post-quantum mechanism so that a session stays secure if either one holds. The most widely deployed example pairs X25519 with ML-KEM-768, usually written X25519MLKEM768. Using the sizes above, the hybrid key share a client sends is the 1,184-byte ML-KEM-768 public key plus the 32-byte X25519 value, about 1.2 kilobytes, which fits within ordinary handshake packets.

Cloudflare's October 28, 2025 post-quantum status report says that the majority of human-initiated traffic to its network now uses post-quantum key agreement. It lists the default-on dates: Chrome on desktop in March 2024 and on Android in November 2024, Firefox on desktop in November 2024, Go in August 2024, OpenSSL in April 2025, and Apple's iOS, iPadOS and macOS 26 rolling out from October 2025. A traffic share measured at one provider reflects the browsers and clients that connect to it, not the whole internet, so it should be read as an indicator of momentum rather than a global figure. Most of the remaining gap is server-side support and older clients.

NIST's own draft guidance treats hybrids as a bridge. It says they are often used as a hedge against a flaw in one component, but that they add complexity and are "typically expected to be temporary measures that lead to a second transition" to PQC-only tools. Hybrid is a way to move early without betting everything on a young algorithm. It is not a destination.

Signatures are the harder half

The same Cloudflare report calls signature migration the harder task. Switching all signatures in a TLS handshake to ML-DSA-44 would add about 15 kilobytes, and using FN-DSA-512 for all signatures except the handshake signature would add about 7 kilobytes, though the report says FN-DSA is difficult to implement safely. It also notes that some clients and middleboxes do not handle certificate chains above 10 kilobytes well, with performance dropping steeply at that size, that post-quantum certificates may appear in 2026 but are unlikely to be broadly trusted before 2027, and that Cloudflare is testing Merkle Tree Certificates with Chrome as a way to shrink the data.

A TLS handshake carries several signatures: one for the server's proof of identity and others embedded in the certificate chain. Each one grows by thousands of bytes. It is like replacing a postcard-sized ID check with a document the length of a short story at every border crossing. Most of the time the cost is tolerable, but on slow networks, embedded devices and high-volume services it shows up as latency and failed connections.

The government timeline

Migration deadlines come from policy, not from physics. NIST's Initial Public Draft of IR 8547, "Transition to Post-Quantum Cryptography Standards," was published on November 12, 2024, with public comments closing January 10, 2025. It quotes National Security Memorandum 10, which sets the goal of mitigating as much quantum risk as is feasible by 2035 across U.S. federal systems.

For signatures, the draft proposes the schedule below. It describes "deprecated" as meaning the algorithm may still be used but the data owner must weigh the risk, and "disallowed" as no longer allowed for the stated purpose.

Algorithm	Security strength	Draft transition
RSA (FIPS 186)	112 bits	Deprecated after 2030, disallowed after 2035
RSA (FIPS 186)	128 bits or more	Disallowed after 2035
ECDSA (FIPS 186)	112 bits	Deprecated after 2030, disallowed after 2035
ECDSA (FIPS 186)	128 bits or more	Disallowed after 2035
EdDSA (FIPS 186)	128 bits or more	Disallowed after 2035

Source: NIST IR 8547 initial public draft, Table 2 (November 2024). A draft can change before it is final, so check the current status of the document before using these dates for planning.

The draft is also candid about uncertainty. It notes that it is difficult to estimate the strength of post-quantum schemes because the performance of future quantum computers is hard to predict, and so it classifies them into five broad security categories pegged to symmetric benchmarks such as AES-128 (category 1), SHA-256 collision search (category 2) and AES-256 (category 5). It also acknowledges that some systems, particularly those with long-term confidentiality needs, may need to move earlier than others.

Why migration is an inventory problem

Cryptography is hidden in dependencies

Organizations often know they use TLS, but may not know every library, certificate, device, firmware image, vendor service, backup format, API gateway, identity provider and embedded system that relies on RSA or elliptic curves. A database may contain encrypted data while the key-management service uses separate public-key mechanisms. Even a passkey login rests on public-key signatures that will eventually need to change.

A cryptographic inventory should record the algorithm, key size, protocol, use case, owner, data lifetime, dependency, upgrade path and replacement constraints. The goal is not merely to count algorithms; it is to understand where a cryptographic failure would matter.

Prioritize by exposure and lifetime

A short-lived public website certificate and a record that must remain confidential for decades do not have the same migration priority. Systems that exchange sensitive data with unknown external parties, control software updates or protect long-lived archives may require earlier planning.

Prioritization should include data sensitivity, retention, adversary interest, update difficulty, supply-chain dependencies and consequences of signature failure. It should not rely on a single global deadline unless a relevant regulator or organization has published one for that environment.

Build an owner for every cryptographic dependency

A migration program fails when cryptography is treated as everyone's responsibility and therefore no team's responsibility. Each system should have an owner who can answer which algorithms are used, who supplies the library, how updates are tested and what happens if an external partner is not ready.

Hybrid migration and algorithm agility

Algorithm agility

Algorithm agility means the system can change cryptographic algorithms without redesigning the entire application. It requires version negotiation, configuration control, safe defaults, key rotation, certificate management, testing and a way to reject obsolete or unsafe options. The SIKE and Rainbow failures are the argument for it: if a scheme can fall in a few years, systems that hard-code it become liabilities.

Agility is not the same as allowing any algorithm supplied by a client. An overly flexible endpoint can expand downgrade risk, where an attacker forces two parties to use the weakest option both support. A secure migration identifies approved suites and controls how transitions occur.

Interoperability is part of security

A cryptographic algorithm that works in one laboratory may fail at the boundaries between browsers, mobile devices, gateways, hardware modules, libraries and partner systems. Test certificates, handshake sizes, fragmentation, error handling, timeouts and observability. Large keys or signatures can expose assumptions that were invisible with older primitives, which is what the certificate-chain size problems above illustrate.

Where PQC migration can be difficult

Transport protocols

TLS and other secure-transport systems may need larger keys, signatures or handshake messages. Middleboxes, packet-size assumptions and embedded implementations can behave unexpectedly. The right migration path depends on the protocol version, software stack and ecosystem. The same concern applies to a VPN, whose tunnels begin with a public-key handshake.

Digital certificates

Certificate authorities, browsers, operating systems, hardware security modules and enterprise trust stores must support new signature types. Certificate chains can become larger, and constrained devices may need firmware or memory changes.

Software updates

PQC is especially important for software-signing systems because a compromised signature mechanism could allow malicious updates. Conversely, changing the signing scheme can break older devices that cannot parse new signatures. Long-lived and difficult-to-update devices need early inventory and realistic transition plans.

Embedded and operational technology

Industrial controllers, vehicles, medical devices, sensors and satellites can remain deployed for years. Their computational, memory, power and communication constraints differ from cloud servers. Migration may require a coordinated update plan, gateway protection or hardware replacement.

Data archives

Encrypted backups often outlive the systems that created them. An archive strategy should document algorithms, keys, rotation, access and re-encryption options. Re-encrypting data can be expensive, but failing to understand the archive's cryptographic dependency is worse.

What PQC does not solve

Post-quantum cryptography does not prevent phishing, stolen credentials, weak passwords, malware, insecure access control, malicious insiders, supply-chain compromise, poor key management or vulnerable endpoints. A quantum-resistant signature can still be used by an unauthorized person if the signing key is stolen. The wider threat picture is covered in our review of cybersecurity threats in 2026.

PQC also does not make a cryptographic implementation correct automatically. Side channels, random-number failures, memory bugs, downgrade paths and certificate-validation errors remain relevant. A standardized primitive can be deployed unsafely. The Open Quantum Safe documentation itself marks some implementations as using large stack memory or not having been checked for branching on secrets, which is the kind of detail that matters in production.

It does not solve the question of who is authorized to access data. It protects particular cryptographic properties under assumptions; it does not replace identity governance or privacy policy.

A practical migration framework

Stage	Main question	Evidence to collect	Common failure
Discover	Where is public-key cryptography used?	Software inventory, certificates, protocols, devices and vendors	Relying only on application documentation
Classify	Which data and functions are most exposed?	Sensitivity, retention, update life and consequences	Treating every system as equally urgent
Select	Which approved algorithms and modes fit?	FIPS status, protocol support, performance and interoperability	Choosing by marketing label alone
Pilot	Can real systems interoperate?	Test handshakes, signatures, sizes, latency and failures	Testing one library in isolation
Migrate	How will changes reach production?	Versioning, rollback, key rotation and change control	No recovery path when partners lag
Verify	Is the old primitive actually gone or controlled?	Scans, certificates, logs and configuration evidence	Leaving hidden legacy paths
Monitor	How will future changes be handled?	Ownership, alerts, crypto-agility tests and standards review	Treating migration as a one-time project

What people get wrong about the quantum threat

Misconception: a countdown clock exists

Quantum computing progress matters, but no one can responsibly state that a cryptographically relevant quantum computer will arrive in a particular year. Hardware progress can be measured in qubits, gate fidelity, logical error rates and algorithmic demonstrations, and the Gidney paper shows that algorithmic progress can cut hardware requirements as much as engineering does. None of these measures is a complete predictor of a future cryptanalytic machine. The planning argument rests on lead time, not on a prediction: if migration takes a decade, waiting for certainty means starting too late.

Misconception: all encryption is about to fail

The threat is specific. Public-key key exchange and signatures based on factoring and discrete logarithms are affected. Symmetric ciphers such as AES and hash functions are treated differently, and NIST does not expect to replace them as part of the PQC transition. A website's data in transit uses both kinds, which is why only part of the handshake needs to change. The what-if scenario of quantum computers breaking all encryption explores the dramatic version of the story; the real one is more incremental.

Misconception: blockchains and the web are equally exposed

Systems differ in what a quantum attack would actually need. Signature schemes protect transactions on public ledgers, and key exchange protects web sessions. Each has different exposure, different upgrade mechanics and different governance. Our primer on what a blockchain is shows why signature changes in a distributed system are slow to coordinate.

Misconception: research results equal deployable security

A laboratory result may demonstrate a new algorithm, logical qubit or hardware architecture. Deploying a secure cryptographic standard requires different evidence: peer review, cryptanalysis, implementation, interoperability, operational support and governance. The SIKE episode shows how a scheme can pass many rounds of review and still fail.

The takeaway

Post-quantum cryptography is a replacement project with a deadline set by lead time rather than by a known quantum milestone. The standards exist, key exchange has already moved into everyday browsing in hybrid form, and the unsolved engineering problem is the size and trust machinery of signatures. The most useful step for any organization is dull and concrete: find out where public-key cryptography lives, rank it by how long the protected data must stay secret, and make sure every system can change its algorithms without being rebuilt. The date a quantum computer arrives matters less than whether the migration is finished before it does.

Limitations

This article does not claim that quantum computers will break encryption on a fixed date, that every RSA or elliptic-curve system is immediately unsafe, that PQC is mathematically immune to future attacks, that one standardized algorithm is best for every deployment, that hybrid modes are automatically secure, that NIST's choices eliminate migration complexity, that a larger key always means stronger security, that a vendor product is certified merely because it mentions PQC, or that migration alone solves identity, endpoint, supply-chain or privacy risks.

The standards and migration recommendations cited here are time-sensitive. IR 8547 was an initial public draft when it was cited, deployment statistics come from one provider's traffic, and FIPS 206 and the HQC standard were still in development at the dates given. Consult the current NIST PQC pages before acting. A real migration requires an organization-specific inventory and qualified cryptographic review. This article is educational and does not provide a cybersecurity migration audit for any specific organization.

Frequently asked questions

Q: What is post-quantum cryptography? A: It is classical cryptography designed to resist attacks from both conventional and future quantum computers under stated mathematical assumptions. It runs on ordinary hardware and mainly replaces public-key key exchange and digital signatures.

Q: Does PQC require a quantum computer? A: No. PQC algorithms run on ordinary computing systems. They are designed for a threat environment in which quantum computers may eventually attack some existing public-key systems, such as RSA and elliptic-curve schemes.

Q: What algorithms has NIST standardized? A: NIST published ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for digital signatures and SLH-DSA (FIPS 205) for hash-based signatures on August 13, 2024. FN-DSA (FIPS 206) was still in development at the last NIST update cited here, and HQC was selected on March 11, 2025 as a backup key-establishment algorithm.

Q: Is ML-KEM an encryption algorithm? A: It is a key-encapsulation mechanism. It helps two parties establish shared secret material over a public channel, and symmetric encryption such as AES normally protects the bulk data using that secret.

Q: What is harvest now, decrypt later? A: It describes collecting encrypted data today with the hope of decrypting it later if cryptographic capabilities improve. Long-lived confidential data deserves particular attention, because the protection must outlast the migration date.

Q: Will quantum computers break all encryption? A: No. Quantum algorithms affect cryptographic families differently. Public-key systems based on factoring or discrete logarithms are the central concern, while NIST does not expect to replace its symmetric-key standards as part of the PQC migration.

Q: Is quantum cryptography the same as post-quantum cryptography? A: No. Quantum cryptography uses quantum physical systems, such as quantum key distribution. PQC uses classical algorithms designed to resist quantum attacks and needs no quantum hardware.

Q: Why are post-quantum signatures harder to deploy than key exchange? A: They are far larger. An ML-DSA-44 signature is 2,420 bytes against 64 for an Ed25519 signature, and a TLS handshake carries several. Cloudflare reports that switching all signatures to ML-DSA-44 would add about 15 kilobytes to a handshake, and some clients and middleboxes handle certificate chains above 10 kilobytes poorly.

Q: Are hybrid classical and PQC modes safer? A: A well-specified hybrid keeps a session secure if either component holds, which hedges against a flaw in a young algorithm. NIST's draft guidance also warns that hybrids add complexity and are typically meant to be temporary, so they are a transition tool rather than a universal guarantee.

Sources

• NIST, NIST releases first 3 finalized post-quantum encryption standards, August 13, 2024.
• NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard and FIPS 204: Module-Lattice-Based Digital Signature Standard, August 13, 2024.
• NIST, NIST selects HQC as fifth algorithm for post-quantum encryption, March 11, 2025.
• NIST, IR 8547 initial public draft, Transition to Post-Quantum Cryptography Standards, November 2024.
• Gidney, C., How to factor 2048 bit RSA integers with less than a million noisy qubits, arXiv, May 21, 2025.
• Castryck, W. and Decru, T., An efficient key recovery attack on SIDH, IACR ePrint 2022/975.
• Cloudflare, The state of the post-quantum Internet, October 28, 2025.
• Open Quantum Safe, liboqs algorithm documentation for ML-KEM, ML-DSA and SLH-DSA.

---

Read next:

• How Encryption Works: Keeping Data Secret
• What If Quantum Computers Broke All Modern Encryption?
• Quantum Internet Explained: What It Is and What It Is Not