Post-Quantum Cryptography Complete Guide

Post-Quantum Cryptography (PQC) is a class of cryptographic algorithms specifically designed to resist attacks from quantum computers. The core difference from traditional encryption is that PQC's security is based on mathematical problems that are hard for both classical and quantum computers to solve.

Traditional asymmetric cryptography relies on three families of mathematical problems: integer factorization (RSA), discrete logarithm (DSA, ElGamal), and elliptic curve discrete logarithm (ECDSA, ECDH). These problems require exponential time on classical computers but can be solved in polynomial time on a quantum computer using Shor's algorithm.

Post-Quantum Cryptography, by contrast, is primarily built on lattice-based cryptography, whose security relies on the Shortest Vector Problem (SVP), Closest Vector Problem (CVP), and Learning With Errors (LWE / Module-LWE). Neither known classical nor quantum algorithms can solve these problems in reasonable time, making lattices the most promising foundation for the post-quantum era.

The NIST PQC standardization timeline is worth noting:

• 2016: NIST issued an open call for post-quantum cryptographic algorithms, launching the standardization process.
• 2017–2018: First round candidates announced — 69 submissions covering public-key encryption, digital signatures, and key exchange, including Kyber, Dilithium, NTRU, Saber, and others.
• 2019: Second round — 26 candidates remained after initial evaluation.
• 2020: Third round — 7 algorithms advanced to the finalist stage.
• 2024: NIST formally published FIPS 203 (ML-KEM / Kyber), FIPS 204 (ML-DSA / Dilithium), and FIPS 205 (SLH-DSA / SPHINCS+).
• 2025 and beyond: Major protocol stacks (TLS 1.3, IPsec, SSH, X.509, OpenSSL, liboqs) are gradually introducing PQC support, while enterprises and government agencies begin quantum-resistant migration.

Beyond lattices, NIST also evaluated hash-based signatures (e.g. SPHINCS+), multivariate quadratic schemes, code-based cryptography, and isogeny-based schemes (e.g. SIKE, later withdrawn). Lattice-based schemes offer the best balance of performance, security, and key sizes, making them the clear winners of this standardization round.

Our online PQC tool currently supports both ML-KEM and ML-DSA, giving developers a hands-on experience of post-quantum key encapsulation and digital signatures.

To understand why post-quantum cryptography matters, we first need to understand how quantum computers threaten traditional cryptography. The foundation of classical cryptography is "certain mathematical problems are hard to solve efficiently on classical computers." Quantum computers break this assumption through fundamentally different computational methods.

Shor's algorithm is the central threat. In 1994, mathematician Peter Shor proved that quantum computers can solve both integer factorization and discrete logarithm in polynomial time — the very problems RSA, ECDSA, and Diffie-Hellman depend on. Critically, Shor's algorithm is not merely theoretical: its quantum resource requirements are within reach of emerging machines.

Breaking RSA-2048, for instance, would require roughly ~40 million logical qubits (with error correction) and thousands of quantum gate operations. Breaking ECDSA-P256 requires even fewer resources. Today's most advanced quantum computers still cannot achieve fault-tolerant large-scale computation, but researchers generally estimate that practically capable quantum computers may emerge by the mid-to-late 2030s.

A more urgent concern is the "Harvest Now, Decrypt Later" attack model:

• Adversaries can mass-record today's encrypted traffic (HTTPS, VPN, TLS handshakes);
• Store the ciphertexts;
• Wait for quantum computers to mature, then break the captured RSA/ECDH session keys offline to recover the original plaintexts.

This means that even if practical quantum computers are still years away, today's sensitive data could be retroactively decrypted in the future. For long-lifetime data — medical records, government secrets, financial contracts, intellectual property — this threat is already real.

Grover's algorithm provides another quantum advantage: it can search N items in O(√N) time, effectively halving symmetric key lengths. AES-128 would reduce to 64-bit classical security; AES-256 to 128-bit classical security. However, Grover's algorithm cannot polynomially speed up symmetric ciphers, so simply doubling key lengths is a sufficient defense. AES-256, SHA-3, and ChaCha20 remain secure in the quantum era. What must be replaced is asymmetric cryptography.

In short, the core problem PQC solves is: find new mathematical problems that quantum computers cannot efficiently solve while remaining efficient on classical computers — to replace RSA, ECDSA, ECDH, and other soon-to-be-vulnerable algorithms.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, formerly known as Kyber) is the only Key Encapsulation Mechanism (KEM) selected in NIST FIPS 203. It replaces RSA/ECDH for key agreement.

Core idea: ML-KEM is based on the Module-LWE (Module Learning With Errors) problem. Intuitively: in a lattice defined by polynomials, finding a "near-lattice point" is easy, but recovering the original "lattice coordinates" is provably hard both classically and quantum-mechanically.

Algorithm flow consists of three functions:

• ML-KEM.KeyGen(): Generates a key pair (pk, sk). The secret key contains a vector of small-coefficient secret polynomials. The public key contains a public polynomial matrix A and a "noisy product" t = A·s + e (where s is the secret vector and e is the error vector).
• ML-KEM.Encaps(pk): Using the receiver's public key, the encapsulator generates a random small-coefficient vector r, computes an "approximate product" u = A^T·r + e1 and v = t^T·r + e2 + encode(shared secret), and finally outputs a ciphertext (u, v) together with a shared key K (derived from the shared secret via hashing).
• ML-KEM.Decaps(sk, ct): The holder of the secret key uses the secret polynomial s to recover an approximate value from u, subtracts this from v to recover the shared secret, and hashes it to derive the same shared key K.

Intuitive understanding: Think of key encapsulation as "putting a message in an envelope that only the recipient's secret key can open." The encapsulator randomly chooses "coordinates to write on the envelope" and encodes the shared key as a small offset inside the envelope. The recipient uses their private key to first compute the correct coordinate position and then subtract the offset to recover the shared key. Without the private key, an attacker cannot precisely infer the shared key due to the noise terms.

ML-KEM offers three parameter sets:

• ML-KEM-512: NIST security level 1, public key ~800 bytes, ciphertext ~768 bytes. Suitable for performance-sensitive scenarios requiring AES-128 equivalent security.
• ML-KEM-768: NIST security level 3, public key ~1,184 bytes, ciphertext ~1,088 bytes. The default recommendation. Already used by Cloudflare, Google Chrome, and OpenSSL in production hybrid key agreements (e.g. X25519+ML-KEM-768).
• ML-KEM-1024: NIST security level 5, public key ~1,568 bytes, ciphertext ~1,568 bytes. The highest security level, AES-256 equivalent, suitable for highly sensitive government and financial systems.

Compared with RSA-2048, ML-KEM-768 has a smaller effective public key, faster key generation, faster encapsulation/decapsulation, and most importantly, quantum resistance. The only "cost" is larger ciphertexts (~1 KB vs RSA's 256 bytes), which is usually acceptable in modern networks.

Our tool fully implements ML-KEM's KeyGen / Encaps / Decaps flow locally in the browser. You can watch key pair generation, encapsulation, decapsulation, and shared key verification in real time.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly known as Dilithium) is the only general-purpose digital signature scheme selected in NIST FIPS 204. It replaces RSA, ECDSA, and EdDSA for message signing and authentication.

Core idea: ML-DSA is also based on the Module-LWE problem, and uses a "rejection sampling" technique to ensure that signatures do not leak information about the private key. Its design follows the classic Fiat-Shamir transform + zero-knowledge proof paradigm, but carefully optimized for lattice structure.

Algorithm flow consists of three functions:

• ML-DSA.KeyGen(): Generates a key pair (pk, sk). The private key contains two small-coefficient polynomial vectors (s1, s2) together with a seed for rejection sampling. The public key contains a public polynomial matrix A, a public polynomial vector t = A·s1 + s2, and hash parameters.
• ML-DSA.Sign(sk, m): Signs message m. Using the private key, the algorithm generates a random "masking vector" y, computes a commitment w = A·y, then hashes the message and commitment to obtain a challenge polynomial c. It then computes z = y + c·s1 and h = w - c·s2 - noise. Finally, rejection sampling checks that the coefficients of z stay within a bound (if not, y is regenerated and the process repeats) to ensure the signature does not leak the secret key structure. The final signature is (z, h, c).
• ML-DSA.Verify(pk, m, sig): The verifier uses the public key to reconstruct the commitment w' = A·z - c·t + h, then rehashes the message with w' to check whether it matches challenge c. If it does, the signature is valid.

Rejection sampling is ML-DSA's key innovation. If z = y + c·s1 were output directly and y were too small, an attacker might infer the distribution of s1 by observing many signatures. Rejection sampling ensures that if z's coefficients are too large, the signature is rejected and regenerated — so the distribution of the final z's does not depend on s1, and all valid signatures follow a nearly identical uniform distribution, effectively thwarting signature leakage attacks.

ML-DSA offers three parameter sets:

• ML-DSA-44: NIST security level 1, public key ~1,312 bytes, signature ~2,420 bytes. Lightweight deployment.
• ML-DSA-65: NIST security level 3, public key ~1,952 bytes, signature ~3,309 bytes. The default recommendation. Currently being trialed by Chrome, Cloudflare, and OpenSSL for X.509 certificate signing.
• ML-DSA-87: NIST security level 5, public key ~2,592 bytes, signature ~4,627 bytes. Highest security level. Suitable for certificate authorities, root certificates, firmware signing, and other long-lifetime use cases.

Compared with ECDSA-P256, ML-DSA-65 produces larger signatures (~3.3 KB vs 64 bytes) and larger public keys (~2 KB vs 64 bytes), but its signing and verification speeds are comparable or faster, and crucially, it resists quantum attacks. In TLS certificate chains, larger signatures increase certificate size by roughly 2–3 KB — typically offset by TLS extensions and compression mechanisms.

Our tool fully implements ML-DSA signing and verification. You can input any message and observe the complete private-key signing and public-key verification flow, as well as verify in real time that "a tampered message will fail verification."

When deploying post-quantum cryptographic algorithms in practice, a key decision is choosing the right parameter level. Different levels trade off key sizes, signature/ciphertext sizes, performance, and security strength. Here's a practical comparison and recommendations.

Security level system

NIST defines five security levels (Category 1 through 5), of which Categories 1, 3, and 5 are widely referenced:

• Category 1: requires at least 2^128 classical operations or 2^64 quantum queries to break. Equivalent to AES-128 security.
• Category 3: requires at least 2^192 classical operations. Equivalent to AES-192.
• Category 5: requires at least 2^256 classical operations. Equivalent to AES-256.

Note: all three levels already account for quantum attackers. So Category 1 already provides "quantum-resistant" capability.

ML-KEM parameter comparison

• ML-KEM-512: Category 1. Public key 800 bytes, ciphertext 768 bytes. Fastest performance. Suitable for embedded devices, lightweight protocols, resource-constrained scenarios.
• ML-KEM-768: Category 3. Public key 1,184 bytes, ciphertext 1,088 bytes. Best balance of performance and security. Default recommended choice. Already used by Cloudflare, Google, and OpenSSL in TLS hybrid key agreements (e.g. X25519+ML-KEM-768).
• ML-KEM-1024: Category 5. Public key 1,568 bytes, ciphertext 1,568 bytes. Highest security level, suitable for highly sensitive long-term data (government, finance, military).

ML-DSA parameter comparison

• ML-DSA-44: Category 1. Public key 1,312 bytes, signature 2,420 bytes. Suitable for lightweight certificates, session authentication.
• ML-DSA-65: Category 3. Public key 1,952 bytes, signature 3,309 bytes. Default recommended choice. Currently being trialed by some root CAs (DigiCert, Sectigo, ISRG Root X2).
• ML-DSA-87: Category 5. Public key 2,592 bytes, signature 4,627 bytes. Highest security level, suitable for root certificates, firmware signing, code signing, and other long-term use cases.

Performance comparison with traditional algorithms (approximate, from public benchmarks)

• Key generation: ML-KEM-768 takes roughly 10–50 microseconds (implementation-dependent), much faster than RSA-2048 (milliseconds). ML-DSA-65 also outperforms RSA-2048.
• Signing / Encapsulation: ML-KEM-768 encapsulation takes tens of microseconds; ML-DSA-65 signing takes hundreds of microseconds. Comparable to or faster than ECDSA-P256.
• Verification / Decapsulation: ML-KEM-768 decapsulation takes tens of microseconds; ML-DSA-65 verification takes hundreds of microseconds. ECDSA verification is relatively slower.
• Key / Signature sizes: This is PQC's only "disadvantage." Compared to 32-byte ECDSA public keys and 64-byte signatures, ML-DSA-65's ~2 KB public keys and ~3.3 KB signatures are roughly 50 times larger. In certificate chains, this adds several kilobytes to TLS Certificate messages.

Practical selection recommendations

• If unsure, default to ML-KEM-768 + ML-DSA-65, the industry-wide recommended combination.
• For embedded devices or bandwidth-constrained environments, prefer ML-KEM-512 + ML-DSA-44.
• For highly sensitive long-term data or high-value transactions, choose ML-KEM-1024 + ML-DSA-87.
• Always use hybrid schemes in all cases (e.g. X25519 + ML-KEM-768, ECDSA-P256 + ML-DSA-65), letting traditional algorithms serve as fallback if any latent flaw is discovered in PQC.

Migrating from classical to post-quantum cryptography is not a one-time replacement — it is a gradual, layered process. Here are 7 battle-tested practical tips for safely transitioning your systems to the quantum-resistant era.

① Use hybrid key agreement (Hybrid KEM)

The industry's current dominant approach combines a traditional key exchange algorithm with a post-quantum KEM, e.g. X25519 + ML-KEM-768. Each party generates one traditional key pair and one PQC key pair; the final session key is derived from both negotiated secrets. This way, even if one path is broken, the session remains secure as long as the other path is safe. Google Chrome, Cloudflare, Mozilla Firefox, OpenSSL 1.3.2+, and BoringSSL have already deployed hybrid KEMs in production.

② Use hybrid digital signatures

In certificates, firmware, and code signing, it is recommended to use both traditional and PQC signatures simultaneously — e.g. ECDSA-P256 + ML-DSA-65. This allows legacy clients that do not support PQC to continue verifying traditional signatures, while giving new clients extra quantum-resistant protection. Certificate authorities like DigiCert and Sectigo are already issuing experimental hybrid-signed certificates.

③ Prioritize "long-lifetime data" scenarios

Not every system needs immediate migration. Prioritize by expected data protection lifetime:

• High priority (protection lifetime > 10 years): Root certificates, firmware signatures, government secrets, medical records, intellectual property, encrypted database backups, VPN long-term keys.
• Medium priority (3–10 years): TLS sessions, API tokens, application-layer encryption keys.
• Low priority (< 3 years): Short-term session keys, ephemeral encryption channels.

④ Never roll your own crypto — use standard libraries

Correctly implementing PQC algorithms is far more complex than classical cryptography. We strongly recommend audited open-source implementations: OpenSSL 3.2+ with ML-KEM / ML-DSA support, liboqs (Open Quantum Safe), BoringSSL, rustls, Circl (Cloudflare's Go implementation), and the WebAssembly implementation used in our tool.

⑤ Key management and rotation

PQC key pair generation is extremely fast (ML-KEM-768 key generation takes only tens of microseconds on modern CPUs), so frequent rotation is both feasible and recommended. Best practice: use ephemeral PQC keys per session (similar to TLS Ephemeral Diffie-Hellman), and set reasonable lifetimes for long-term keys (e.g. 1–2 years).

⑥ Evaluate ciphertext/signature size impact on protocols

PQC ciphertexts and signatures are 10–100 times larger than their classical counterparts. This may impact: TLS Certificate message sizes, DNSSEC response sizes, IPsec packet sizes, firmware update package sizes. Before migration, verify that existing network infrastructure can accommodate larger messages and whether MTU adjustments are needed.

⑦ Keep backward compatibility — don't rush to remove classical algorithms

Although post-quantum cryptography has reached standard status, it still continues to undergo open review by the global cryptography community. Over the next 5–10 years, the recommended approach is hybrid mode (classical + PQC) rather than full removal of classical cryptography. This way, even if theoretical flaws are discovered in a PQC algorithm some day, classical cryptography still provides a baseline defense. Similarly, keep an eye on NIST's ongoing standardization and prepare contingency plans for algorithm switching.

Our online tool helps you experience the complete ML-KEM and ML-DSA flow, and is a great place to learn and validate before real-world migration.

🔒 Local browser computation: Our PQC tool runs entirely in your browser. All ML-KEM encapsulation/decapsulation, ML-DSA signing/verification, and key pair generation happen locally in the JavaScript engine and WebAssembly module. Your public keys, private keys, ciphertexts, signatures, and messages are never uploaded to any server, nor logged anywhere. The tool works even without network connectivity.

🛡️ Safe-use recommendations: When processing sensitive data with this tool, we recommend operating in a private browsing window with browser extensions/plugins disabled, and ensuring your device is free of malware. Do not process highly sensitive information on public computers or untrusted devices. When finished, clear your browser cache promptly and close the page.

⚡ High-performance computation: Our tool uses a high-performance WebAssembly-based implementation. On a typical laptop, ML-KEM-768 key generation takes tens of milliseconds, encapsulation/decapsulation takes milliseconds; ML-DSA-65 signing takes tens of milliseconds. This fully meets daily development, learning, and testing needs.

🌐 Open source and transparent: We use industry-standard post-quantum cryptography implementations. The algorithmic logic is open and transparent to all users, ensuring no hidden behavior. Data security and privacy are our core commitments.

⚠️ Legal compliance notice: Please ensure that your use of this tool complies with the laws and regulations of your country and region. This tool is intended only for legal data protection, development, testing, and learning purposes. Any illegal use is strictly prohibited.

💡 Final reminder: Post-quantum cryptography is a rapidly evolving discipline. This article provides conceptual introduction and practical advice, and is not a substitute for professional security auditing. When deploying post-quantum cryptographic schemes in production systems, we strongly recommend consulting professional cryptographers or security engineers. Our online PQC tool can serve as a helpful aid in your daily development and learning, but production-grade security requires systematic safeguards.