Three ways to keep a secret — RSA, ECC, PQC, QKC

Foundations

What cryptography is for, the hard problems it rests on, and why quantum computers change the picture.

Cryptography is the quiet layer under almost every digital system: it protects data in transit and at rest, proves who you are talking to, and makes tampering detectable.

Goal	Question it answers	Typical tools
Confidentiality	Can only the intended party read it?	AES-GCM, ChaCha20-Poly1305, key exchange
Integrity	Was it changed on the way?	MACs (HMAC), AEAD tags, hashes
Authentication	Who sent it, who am I talking to?	Digital signatures, certificates, MACs
Non-repudiation	Can the signer later deny it?	Digital signatures with trusted timestamps

Where it lives in real infrastructure

System	Cryptography inside	Quantum-vulnerable part
HTTPS / TLS	ECDHE key exchange, certificate signatures, AES-GCM	Key exchange, signatures
SSH, VPN (IPsec, WireGuard)	Diffie–Hellman, host and user keys, symmetric tunnels	Key exchange, authentication keys
PKI and code signing	CA hierarchies, RSA/ECDSA signatures on certificates and software	All signatures
Payments, smart cards, eSIM	Symmetric keys in secure elements, RSA/ECC for provisioning	Provisioning and card authentication
Disk and database encryption	AES with keys wrapped by other keys	Only if key wrapping uses RSA/ECC
DNSSEC, email (S/MIME, PGP)	Signatures, public-key encryption	Signatures and encryption

From classical to modern

Antiquity – 1800s: substitution and transposition ciphers (Caesar, Vigenère). Security came from keeping the method secret.
1883: Kerckhoffs' principle — a system must stay secure even if everything except the key is public.
1920s–1940s: rotor machines such as Enigma; their breaking showed that weak key handling and operator habits defeat strong machines.
1949: Shannon's information theory of secrecy: the one-time pad is perfectly secure, but needs a key as long as the message.
1976–1977: Diffie–Hellman key exchange and RSA create public-key cryptography; DES becomes the first public encryption standard.
1984–1985: BB84 quantum key distribution; elliptic-curve cryptography proposed by Koblitz and Miller.
1994–1996: Shor's and Grover's quantum algorithms show that quantum computers would break RSA/ECC and weaken brute-force resistance.
2001: AES replaces DES. 2015: SHA-3 standardized.
2016–2024: NIST's public PQC competition; FIPS 203, 204 and 205 published in August 2024.

Symmetric and asymmetric models

	Symmetric	Asymmetric (public-key)
Keys	One shared secret key	A public and private key pair
Speed	Very fast, hardware-accelerated (gigabytes per second)	Much slower; used on small values
Main job	Encrypt and authenticate bulk data	Establish keys, sign, authenticate
Key distribution	Hard: the key must be shared secretly first	Easy: the public key can be published
Keys needed for N users	N(N−1)/2 pairwise keys	N key pairs
Examples	AES, ChaCha20, HMAC, SHA-2/3	RSA, ECDH, ECDSA, ML-KEM, ML-DSA
Quantum impact	Grover halves effective strength — use 256-bit keys	Shor breaks RSA/ECC — replace with PQC

Real workflows combine them. Asymmetric cryptography sets up or authenticates a short secret; symmetric cryptography carries the data:

1. Key exchangeECDH / ML-KEM

shared secret

2. Derive keysHKDF

session keys

3. Encrypt dataAES-GCM

Constructing a key exchange

Diffie–Hellman lets two systems agree on a secret over a public network. Both agree on a prime p and generator g; each picks a private number, publishes g^private mod p, and raises the other side's value to its own private number. Both arrive at g^(ab) mod p. An eavesdropper sees p, g, A, B — recovering a or b is the discrete logarithm problem.

Simulate a key exchange between two systems

Change the private keys. The shared secret is then fed to a key-derivation function (here real SHA-256, as inside HKDF) to produce a 128-bit session key.

Prime p Generator g Alice's private a Bob's private b

Unauthenticated DH is open to man-in-the-middle. Mallory can run one exchange with Alice and another with Bob. That is why TLS signs the exchange with the server's certificate key. Real DH uses 2048-bit+ groups or elliptic curves (X25519) — and both fall to Shor's algorithm, which is why ML-KEM is replacing them.

Hard mathematical problems

Public-key cryptography needs one-way functions with a trapdoor: easy to compute, hard to invert, easy again with a secret.

Problem	Used by	Best classical attack	Quantum status
Integer factorization	RSA	General number field sieve, sub-exponential	Shor: polynomial
Discrete logarithm mod p	Diffie–Hellman, DSA	Number field sieve, sub-exponential	Shor: polynomial
Elliptic-curve discrete log	ECDH, ECDSA, EdDSA	Pollard's rho, fully exponential (√ of group size)	Shor: polynomial
Module-LWE, Module-SIS	ML-KEM, ML-DSA	Lattice reduction (BKZ), exponential	No known speedup beyond small factors
Syndrome decoding	Classic McEliece, HQC	Information-set decoding, exponential	Only Grover-type speedup
Hash preimage / collision	SLH-DSA, LMS, XMSS	Generic search	Grover: square-root speedup only

What RSA and ECC actually assume

RSA assumption: computing e-th roots modulo n is hard. Factoring n breaks it; whether breaking it requires factoring is not proven.
Diffie–Hellman assumptions: computing g^ab from g^a, g^b (CDH) — and even distinguishing it from random (DDH) — is hard. Both reduce to, but may be easier than, the discrete log.
Parameter assumptions: primes are random and large, curves are well-chosen, randomness is good. Most real breaks violate these rather than the math.

Complexity theory in cryptographic security

Class	Meaning	Relevance
P	Solvable in polynomial time on a classical computer	What defenders do: encrypt, sign, verify
NP	Solutions verifiable in polynomial time	Factoring and discrete log are in NP, but are not believed NP-complete
BQP	Solvable in polynomial time on a quantum computer	Contains factoring and discrete log (Shor) — the root of the quantum threat

No security is proven absolutely. We do not even know whether one-way functions exist (it would imply P ≠ NP). Security means "no efficient attack is known after years of public scrutiny".
Reductions: a scheme is "provably secure" if breaking it would solve a well-studied hard problem. The proof is only as good as the problem and the model.
Average case matters: cryptography needs problems that are hard for random instances, not just the worst case. Lattice problems are special: Ajtai and Regev linked average-case LWE to worst-case lattice problems.
Security level: "128-bit security" means the best known attack takes about 2¹²⁸ operations.

How attack cost scales with key size

Approximate work (log₂ operations) to break RSA with the classical number field sieve, compared with a rough cubic gate count for Shor's algorithm. Drag to pick a key size.

RSA modulus: 2048 bits

Classical cost grows sub-exponentially, so doubling the key adds a lot of security. Shor's cost grows only polynomially, so bigger RSA keys buy almost nothing once a large quantum computer exists. Figures are order-of-magnitude estimates.

Simulate a factoring attack on RSA-like keys

Enter a public modulus n and exponent e. The attacker factors n with Pollard's rho, rebuilds the private key, and decrypts. Try n = 3233 (61 × 53), then larger values like 1000000016000000063.

Modulus n Exponent e Ciphertext c

Cryptographic failures and their lessons

Incident	What went wrong	Lesson
Debian OpenSSL (2008)	A code cleanup removed entropy; only ~32,768 possible keys were generated for two years	Randomness is a single point of failure
Sony PS3 (2010)	ECDSA signatures reused the same nonce, revealing the console's private signing key	Nonces must never repeat; prefer deterministic or hedged signing
Heartbleed (2014)	A missing bounds check in OpenSSL leaked server memory, including private keys	Implementation bugs bypass strong math
Logjam, FREAK (2015)	Servers could be downgraded to weak "export-grade" DH and RSA	Remove weak options; resist downgrades
ROCA (2017)	A smart-card library generated RSA primes with structure, making millions of keys factorable	Key generation needs review as much as algorithms
SHAttered (2017)	First practical SHA-1 collision, after warnings since 2005	Migrate when weaknesses appear, not when attacks are cheap
Dual_EC_DRBG (2013)	A standardized random generator was believed to contain a backdoor	Demand transparent parameter choices
SIKE (2022)	A PQC finalist broken in about an hour on a laptop by a new mathematical attack	New assumptions need years of scrutiny; keep hybrid and crypto-agile

The pattern repeats: algorithms rarely fail first. Randomness, implementation, configuration and slow migration do. PQC migration will be judged by the same lessons.

Next chapterRSA: public-key encryption from factoring

RSA

Encrypt with one key; only the other key can decrypt.

RSA is a foundation of public-key cryptography: two parties can exchange data securely without ever having shared a secret. Rivest, Shamir and Adleman published it in 1977.

With symmetric cryptography such as AES, both sides use the same key — fast, but they need a safe way to hand that key over. Public-key cryptography solves this with a mathematically linked key pair: the public key can be shared freely, the private key never leaves its owner.

Picture a pile of boxes with open padlocks left in a public place. Anyone can snap a lock shut, but only you hold the key that opens it. The padlock is the public key, the key is the private key, and both are made of math.

Public key

Shared with everyone. Used to encrypt messages to you, or to verify your signatures.

Private key

Kept only by you. Used to decrypt, or to sign.

Easy one way, hard the other

Multiplying two primes is fast. Recovering the two factors from their product becomes enormously expensive once the number is thousands of bits long.

17 × 19 = 323 easy 323 = ? × ? harder as numbers grow

Note. RSA is not just "multiply two primes and call it secure". Key size, key generation, padding scheme and implementation all determine its security.

Generating a key pair

Pick two primes: p = 3, q = 11.
Compute the modulus: n = p·q = 33.
Compute Euler's totient: φ(n) = (p−1)(q−1) = 2·10 = 20.
Choose the public exponent e = 3, since gcd(3, 20) = 1.
Find the private exponent d = 7, since 3·7 = 21 ≡ 1 (mod 20).

Result: public key (33, 3), private key (33, 7). In practice p and q are each at least 1024 bits, drawn from a cryptographic random number generator, and e is usually 65537.

e · d ≡ 1 (mod φ(n))

d is the modular inverse of e modulo φ(n). That is what makes modular exponentiation reversible.

φ(n) or λ(n)? Introductory texts use Euler's φ(n). The RSA standards (RFC 8017, FIPS 186-5) use Carmichael's λ(n) = lcm(p−1, q−1), which gives a smaller d that works just as well. Here λ(33) = lcm(2, 10) = 10, and 3·7 = 21 ≡ 1 (mod 10) — still d = 7. Real private keys also store p, q and a few helper values to speed up decryption with the Chinese Remainder Theorem.

Encryption and decryption

The sender only needs the public key. For the message m = 4:

c = m^e mod n = 4³ mod 33 = 64 mod 33 = 31

The recipient uses the private key. Since 31 ≡ −2 (mod 33):

m = 31⁷ mod 33 = (−2)⁷ mod 33 = −128 mod 33 = 4

Message4

power 3, mod 33

Ciphertext31

power 7, mod 33

Recovered4

Why do the two operations cancel?

Because ed = 21 = 1 + φ(n), we get m^ed = m · m²⁰. By Euler's theorem, when gcd(m, 33) = 1, m²⁰ ≡ 1, so m^ed ≡ m (mod 33). The case where m shares a factor with n still works, thanks to the Chinese Remainder Theorem.

Never use this formula directly. Real RSA needs a padding scheme such as RSA-OAEP. The bare formula is deterministic: the same m always gives the same c, so an attacker can guess candidates and compare.

Try RSA with small numbers

Change p, q, e or the message. Results update as you type.

p q e Message m

A teaching model only — completely insecure for real data.

Encryption is not signing

Encryption

The sender uses the recipient's public key; the recipient decrypts with their own private key. Goal: keep the content secret.

Digital signature

The signer uses their own private key; anyone can verify with the public key. Goal: prove origin and detect tampering.

Alice hashes the document and signs the hash with her private key using RSA-PSS.
Alice sends the document and the signature to Bob.
Bob verifies with Alice's public key. A valid result means the document was not altered and was signed by whoever holds the matching private key.

A signature does not prove a real-world identity on its own. PKI and certificates are needed to bind a public key to the right person or organization.

Hybrid encryption

RSA is slow and can only encrypt small amounts of data, so real systems combine two layers:

Generate a random AES key.
Encrypt the data with AES-GCM — fast, and it detects tampering.
Encrypt the AES key with RSA-OAEP under the recipient's public key.
Send both. The recipient unwraps the AES key with their private key, then decrypts the data.

TLS 1.3 no longer uses RSA to transport session keys; it uses (EC)DHE key exchange instead. RSA now mostly appears as a signature in certificates.

How secure is RSA?

Anyone who factors n = pq can compute φ(n) and derive d. In practice, though, systems usually break elsewhere: weak prime generation, leaked keys, side-channel attacks, or legacy padding.

Scheme	Used for	Notes
RSA-OAEP	Encryption	Randomized padding; the default choice
RSA-PSS	Signatures	Randomized padding; the default choice
PKCS#1 v1.5	Encryption (legacy)	Hit by Bleichenbacher attacks; kept only for compatibility

Next chapterECC: elliptic curves

Elliptic curves

The same classical security as RSA, with keys many times smaller.

Elliptic-curve cryptography (ECC) works with points on a curve over a finite field. Despite the name, an elliptic curve is not an ellipse. The short Weierstrass form:

y² ≡ x³ + ax + b (mod p)

"Finite field" means all arithmetic wraps around modulo a prime p. The curve's points, plus a point at infinity, form a group, and the core operation is repeated point addition — called scalar multiplication.

Q = d · G

G is a public generator point, fixed for each standard curve.
d is the private key: a random number in the allowed range.
Q is the public key: G added to itself d times.

Computing Q from d is fast (double-and-add takes about log₂d steps). Recovering d from G and Q is the elliptic-curve discrete logarithm problem (ECDLP) — designed to be infeasible for good curves and large enough parameters.

Adding two points

For two distinct points P = (x₁, y₁) and R = (x₂, y₂):

s = (y₂ − y₁) / (x₂ − x₁) x₃ = s² − x₁ − x₂ y₃ = s(x₁ − x₃) − y₁ (mod p)

"Division" in a finite field means multiplying by a modular inverse. When doubling a point (P = R), the slope becomes s = (3x₁² + a) / 2y₁. Real implementations must also handle special cases and validate that points lie on the curve.

ECC is not one curve. Deployments use standardized curves: NIST P-256, Curve25519. X25519 is for key agreement (RFC 7748), Ed25519 is for signatures (RFC 8032) — related, but not interchangeable.

Try ECC on a toy curve

Curve y² = x³ + 2x + 2 (mod 17), generator G = (5, 1). Pick a private key d and watch where the public key Q = dG lands.

Private key d7

Public key Q = dG…

Group size…

Each dot is a solution (x, y) in the finite field, not a continuous curve. The line traces G, 2G, 3G… — it jumps around seemingly at random, which is exactly why walking back from Q to d is hard. This group is far too small to be secure.

RSA vs ECC

	RSA	ECC
Hard problem	Integer factorization	Elliptic-curve discrete logarithm
Public key	Modulus and exponent	A curve point, plus curve parameters
Common schemes	RSA-OAEP to encrypt, RSA-PSS to sign	ECDH / X25519 for key agreement, ECDSA / Ed25519 to sign
Key size for ~128-bit security	3072 bits	256 bits
Typical implementation bugs	Padding oracles, weak primes, timing leaks	Nonce reuse when signing, invalid-curve attacks, missing point validation
Against quantum computers	Broken by Shor	Broken by Shor

ECC usually gives smaller keys and efficient operations, but "smaller" does not automatically mean "faster" or "safer" in every case. The right choice depends on the protocol, hardware, interoperability and implementation quality.

Public-key cryptography in practice

Hybrid encryption

Public keys only establish a short-lived symmetric key. The data is encrypted with AES-GCM or ChaCha20-Poly1305.

Certificates and trust

A certificate binds a public key to an identity and is signed by a CA. Clients must check the chain, hostname, validity period and policy.

A modern HTTPS connection (TLS 1.3), conceptually:

Both sides agree on a session secret with ephemeral Diffie–Hellman, usually ECDHE with X25519.
The server proves its identity with a signature from its certificate key (RSA-PSS, ECDSA or Ed25519).
From the shared secret, both derive traffic keys with a KDF.
Data is encrypted with authenticated encryption (AEAD).

This is not a full TLS handshake. Always use a maintained TLS library; never implement the protocol yourself.

The quantum threat to both RSA and ECC

A large, error-corrected quantum computer running Shor's algorithm would factor integers and solve discrete logarithms in polynomial time. That breaks RSA, Diffie-Hellman and ECC at once. Today's machines cannot do this for real key sizes, but there are two reasons to prepare now:

Harvest now, decrypt later

Attackers can record encrypted traffic today and wait for a quantum computer. Data that must stay secret for 10–20 years is already at risk.

Migration is slow

Replacing algorithms across protocols, certificates, hardware and embedded devices usually takes a decade.

Grover's algorithm only gives a square-root speedup on brute-force search, so symmetric cryptography is affected differently: longer keys are enough — AES-256 and SHA-384 remain secure. The problem is public-key cryptography, and there are two answers: replace the math (PQC) or replace it with physics (quantum key cryptography, QKC).

Next chapterPQC: post-quantum cryptography

Post-quantum cryptography

New math, running on the computers we already have.

Post-Quantum Cryptography (PQC) is a set of algorithms that run on ordinary computers but rest on problems believed to be hard for both classical and quantum machines. No new hardware is needed — only software and protocol updates.

Family	Hard problem	Algorithms
Lattices	Module-LWE, NTRU: finding short vectors, removing noise in high-dimensional space	ML-KEM, ML-DSA, FN-DSA
Hash-based	Relies only on the security of hash functions	SLH-DSA, XMSS, LMS
Code-based	Decoding a random linear error-correcting code	HQC, Classic McEliece

NIST standards

Algorithm	Standard	Role	Status
ML-KEM (Kyber)	FIPS 203	Key encapsulation, replacing RSA/ECDH key exchange	Final, Aug 2024
ML-DSA (Dilithium)	FIPS 204	Digital signatures, the default choice	Final, Aug 2024
SLH-DSA (SPHINCS+)	FIPS 205	Backup signatures based only on hash functions	Final, Aug 2024
FN-DSA (Falcon)	FIPS 206	Compact signatures	Draft, final expected late 2026 – early 2027
HQC	—	Backup KEM on a different math basis than ML-KEM	Selected Mar 2025, being standardized

KEMs instead of "encrypt with the public key"

PQC does not encrypt messages directly the way RSA does. Instead, a key encapsulation mechanism (KEM) gives both sides a shared secret:

Bob generates a key pair (ek, dk) and publishes ek.
Alice runs Encaps(ek), gets a shared secret K and a ciphertext ct, and sends ct.
Bob runs Decaps(dk, ct) and also obtains K. Both use K as an AES key.

Intuition for Learning With Errors

b = A·s + e (mod q)

The matrix A is public, the vector s is secret, and e is small noise. Without the noise, finding s is just solving linear equations. Add the noise and the problem becomes extremely hard — even for quantum computers, as far as we currently know.

A KEM authenticates no one. ML-KEM only gives two parties a shared secret; it does not prove who you are talking to. If the surrounding protocol does not authenticate with signatures or trusted keys, a man-in-the-middle can still get in.

FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, offering different security/performance trade-offs. Bigger is not "better for every case" — pick according to a standard protocol profile. In a full connection, the KEM secret goes through a KDF to become traffic keys, and AES-GCM or ChaCha20-Poly1305 encrypts the data.

Intuition for lattices: picture a regularly repeating grid of points in hundreds of dimensions. Whoever holds the secret key "knows a shortcut" to strip off the noise; an attacker only sees a problem believed to be hard. "Quantum-resistant" means designed to withstand known quantum attacks under stated assumptions — not proven unbreakable.

The cost: size

Algorithm	Public key	Ciphertext or signature
X25519	32 B	32 B
RSA-3072	384 B	384 B
ML-KEM-768	1,184 B	1,088 B
ML-DSA-65	1,952 B	3,309 B
SLH-DSA-128s	32 B	7,856 B

PQC is often fast, but keys and signatures are much larger — which affects bandwidth, certificate chains and embedded devices.

Encrypt one bit with Learning With Errors

A toy version of Regev's 2005 scheme, the ancestor of ML-KEM: n = 8 secret numbers, q = 97, 16 public samples. Raise the noise and watch decryption start to fail.

Bit to send Noise per sample: ±2

How it works: the public key is many noisy equations bᵢ = ⟨aᵢ, s⟩ + eᵢ (mod q). To send a bit, add up a random subset of them, then add ⌊q/2⌋ if the bit is 1. The receiver subtracts ⟨u, s⟩; what remains is the bit's offset plus the sum of the small errors. If that noise stays under q/4, rounding recovers the bit. Real schemes pick parameters so the chance of a failure is astronomically small.

Inside ML-KEM

Module-LWE: instead of plain numbers, entries are polynomials in Z₃₃₂₉[X]/(X²⁵⁶+1), arranged in small k×k matrices (k = 2, 3, 4 for ML-KEM-512, 768, 1024). The structure makes keys compact and arithmetic fast.
Number-theoretic transform (NTT): a finite-field cousin of the FFT that multiplies those polynomials quickly. It is why ML-KEM is often faster than X25519 in software.
Fujisaki–Okamoto transform: the inner encryption is only secure against passive attackers. The FO transform re-encrypts during decapsulation and checks the result, upgrading it to IND-CCA2 security against active attackers. On a mismatch it returns a pseudorandom key (implicit rejection) rather than an error, so attackers learn nothing.
Decryption failures: like the toy above, ML-KEM can in principle fail, but the probability is below 2⁻¹³⁸ for every parameter set — far less likely than a hardware fault.

Inside ML-DSA

Fiat–Shamir with aborts: the signer commits to a random masking vector, derives a challenge from the message hash, and computes a response.
Rejection sampling: if the response would leak information about the secret key, the signer throws it away and tries again. On average a signature takes a few attempts.
Hedged signing: FIPS 204 mixes fresh randomness with a deterministic seed, protecting against both bad RNGs and fault attacks.

Hash-based signatures: stateless and stateful

SLH-DSA (stateless) can sign without remembering anything, at the cost of large signatures. LMS and XMSS (NIST SP 800-208) are stateful: smaller and faster, and already approved for firmware signing, but every one-time key may be used only once. Reusing state — after a VM snapshot restore or an HSM failover — can let attackers forge signatures. They suit tightly controlled signing servers, not general use.

Security levels and sizes

NIST rates PQC parameter sets by categories tied to familiar benchmarks: category 1 is at least as hard to break as AES-128, category 3 as AES-192, category 5 as AES-256.

Parameter set	Category	Public key	Ciphertext / signature
ML-KEM-512	1	800 B	768 B
ML-KEM-768	3	1,184 B	1,088 B
ML-KEM-1024	5	1,568 B	1,568 B
ML-DSA-44	2	1,312 B	2,420 B
ML-DSA-65	3	1,952 B	3,309 B
ML-DSA-87	5	2,592 B	4,627 B
SLH-DSA-128s / 128f	1	32 B	7,856 / 17,088 B
SLH-DSA-256s	5	64 B	29,792 B
FN-DSA-512 (draft)	1	897 B	≈ 666 B
Classic McEliece 348864	1	261,120 B	96 B

Size comparison

Bytes on the wire, log scale. Switch between key exchange and signatures.

Post-quantum signatures

Signatures answer a different question than key exchange: who produced this message, and has it been altered? Signatures protect software updates, certificates and documents — but they do not encrypt content, and they do not prove the content is true.

Algorithm	Basis	Strengths	Trade-offs
ML-DSA	Lattices	General-purpose signatures; the default candidate for new deployments	Keys and signatures larger than ECDSA; check protocol support
SLH-DSA	Stateless hash-based	A completely different math basis from lattices — diversifies risk	Large signatures; signing speed varies widely by parameter set

Using several algorithms avoids depending on one math family, but each extra path needs implementation, testing, key management and monitoring. Don't add one "just in case".

Other families

Classic McEliece (code-based) has been studied since 1978 and has a conservative design, but its public keys run to hundreds of KB — awkward for bandwidth-constrained protocols. Multivariate and isogeny-based schemes were proposed too; prominent candidates such as Rainbow and SIKE were broken in 2022. The lesson: a "quantum-resistant" label is no substitute for years of public cryptanalysis and standardization.

Which problem are you solving?

Pick a situation to see where to start.

Common misconceptions

Misconception	Reality
PQC means using a quantum computer	PQC runs on ordinary computers; it is only designed to resist quantum attacks.
ML-KEM encrypts all my data	It only creates a shared secret; authenticated symmetric encryption protects the data.
One PQC algorithm makes the whole system quantum-safe	Protocols, signatures, certificates, identity, endpoints, key storage and backups all count.
We can wait until quantum computers exist	Migration takes years, and data captured today can be decrypted later.
Hybrid designs are always safer	Only when the combination is standardized and correctly implemented. Don't invent your own combiner.

Engineering costs to measure

Latency: measure full handshakes and tail latency, not just one primitive's benchmark.
Bandwidth: certificates, signatures, KEM ciphertexts, and worst-case packet fragmentation.
Memory and hardware: peak RAM, code size, HSM or secure-element support, power draw.
Interoperability: both ends, middleboxes and certificate infrastructure must support the same standard protocol.
Failure behavior: downgrade resistance, malformed input, timeouts, retries and safe fallback.

Where PQC already runs

System	What changed
Web (TLS 1.3)	Chrome, Firefox, Edge and Cloudflare negotiate the hybrid X25519MLKEM768 by default; a large share of browser traffic is already post-quantum for key exchange.
OpenSSH	Hybrid post-quantum key exchange by default since version 9.0 (2022); version 10.0 (2025) made mlkem768x25519-sha256 the default.
OpenSSL	Version 3.5 (2025) added ML-KEM, ML-DSA and SLH-DSA.
Messaging	Signal added the PQXDH handshake (2023); Apple's iMessage moved to the PQ3 protocol (2024).
Certificates	Still mostly classical. Post-quantum and composite (classical + PQC) certificates are being standardized at the IETF; signature size is the main obstacle.

Notice the pattern: key exchange moved first, because harvest-now-decrypt-later only threatens confidentiality. Signatures can be swapped later, as long as it happens before a quantum computer exists — a forged signature cannot be produced retroactively for a past session.

Implementation pitfalls already seen

Timing leaks: "KyberSlash" (2023–24) showed that a division instruction in several Kyber implementations leaked secret-dependent timing. Constant-time code matters as much as for RSA and ECC.
Side channels and faults: power analysis and fault injection on smart cards and microcontrollers are active research areas for lattice schemes.
Randomness: ML-KEM key generation and encapsulation still need a good RNG.

Deadlines

Who	Plan
NIST IR 8547 (US, draft)	RSA, ECDSA, ECDH and finite-field DH at 112-bit security deprecated after 2030, disallowed after 2035. Hybrid modes with an approved PQC algorithm stay allowed.
NSA CNSA 2.0 (US national security systems)	New acquisitions quantum-resistant from 2027; all national security systems by 2035.
EU coordinated roadmap (June 2025)	National PQC roadmaps and first steps by end of 2026; high-risk use cases migrated by end of 2030; everything by end of 2035.
UK NCSC	Discovery and planning by 2028; high-priority migrations by 2031; complete by 2035.

Am I already late? Mosca's inequality

Michele Mosca's rule of thumb: if the time your data must stay secret (x) plus the time you need to migrate (y) is longer than the time until a cryptographically relevant quantum computer (z), you are already exposed.

x · data must stay secret: 10 yrs y · migration takes: 5 yrs z · quantum computer arrives in: 12 yrs

Nobody knows z. Expert surveys spread it from under a decade to never — which is why planners pick a cautious value.

Migration plan

The transition uses hybrid mode: pairing a classical algorithm with a PQC one, such as X25519MLKEM768 in TLS 1.3 — already on by default in major browsers and at Cloudflare. An attacker would have to break both. Migration is an inventory and engineering program, not a rename.

Discover: find every use of cryptography — certificates, TLS, VPNs, code signing, software updates, device identity, stored data, HSMs, vendor libraries.
Prioritize: long-lived secrets, systems exposed to interception, hard-to-update devices, trust roots and the software supply chain.
Test: use maintained standard libraries, try hybrid KEMs where the protocol supports them, measure size, latency, CPU and memory.
Deploy and monitor: assign owners, track vendor roadmaps, record exceptions and deadlines, retest after every upgrade.

Example prioritization

Asset	Secrecy lifetime	Migration difficulty	Action
Sensitive archives	Long	Medium	Assess harvest-now-decrypt-later risk; plan re-encryption
Public TLS services	Varies	Medium	Inventory libraries and certificates; test supported hybrid KEMs
Code-signing infrastructure	Long-lived trust	High	Plan PQC signatures, trust-anchor changes, firmware limits
Rarely updated embedded devices	Varies	High	Start early; test memory, bandwidth, update size

Deployment checklist

Tick what's done.

Inventory algorithms and where they are used, including indirect dependencies and vendor products.
Classify data by how long it must stay confidential and the impact of future decryption.
Separate use cases: key exchange, signatures, certificates, code signing, stored data, device identity.
Use current NIST standards and maintained libraries; confirm support with vendors.
Only test hybrid key exchange where it is standardized or officially supported; don't build your own combiner.
Plan certificate and trust-store changes, key rotation, recovery, logging and incident response.
Document owners, exceptions, dependencies, deadlines and a regular reassessment cycle.

Next chapterQKC: quantum key cryptography

Quantum key cryptography

An eavesdropper cannot look without touching.

Quantum key cryptography (QKC) — usually just called quantum cryptography — is the family of cryptographic tools whose security comes, wholly or partly, from quantum mechanics rather than from hard math problems. It rests on a handful of physical facts:

Quantum effect	What it gives cryptography
Measurement disturbance	Reading an unknown state changes it, so spying leaves a trace
No-cloning	Unknown quantum states cannot be copied — no "record now, read later" on the quantum channel
Intrinsic randomness	Measurement outcomes are genuinely unpredictable, not just hard to predict
Entanglement and Bell nonlocality	Correlations that can certify security even without trusting the devices

Its first and most mature member is quantum key distribution (QKD), so most of this chapter is about QKD. The later sections cover the rest of the toolkit: quantum randomness, signatures, secret sharing, direct communication, delegated computation — and the tasks quantum physics provably cannot secure.

QKC is not PQC. PQC is new math on classical computers. QKC uses quantum states sent over a quantum channel, usually photons in fiber or free space.

QKD, the core of QKC

Quantum Key Distribution (QKD) uses single photons to let two parties create a shared secret key. Its security comes from the laws of physics, not computational difficulty — so no quantum computer, however powerful, helps an attacker.

Measurement disturbs

Measuring a photon in the wrong basis changes its state. Taking information always leaves a trace.

No copying

The no-cloning theorem: nobody can perfectly copy an unknown quantum state, so Eve cannot "photograph" a photon and measure it later.

QKD only creates keys. Data is still encrypted with AES, or a one-time pad if the key rate is high enough. QKD's security analysis rests on quantum mechanics together with explicit assumptions about devices, implementation and an authenticated classical channel.

QKD can

Give two endpoints shared random key material.
Detect certain kinds of eavesdropping through a rising error rate.
Offer a security basis entirely different from computational hardness.

QKD cannot

Encrypt application data by itself.
Skip authentication of the classical channel.
Protect compromised endpoints or faulty hardware.
Replace all of public-key cryptography.

The BB84 protocol

Proposed by Bennett and Brassard in 1984. Each bit is encoded in a photon's polarization, in one of two bases:

Basis	Bit 0	Bit 1
Rectilinear ( + )	↕	↔
Diagonal ( × )	⤢	⤡

Alice picks a random bit and basis for each photon and sends it.
Bob measures each photon in a random basis. Matching basis means he reads the right bit; mismatched basis gives a 50/50 result.
Over an authenticated classical channel, they announce bases (not bits) and keep only matching positions — about half.
They publicly compare a sample to compute the error rate, QBER. If Eve intercepts and resends every photon, QBER rises to about 25%.
If QBER is below threshold (about 11% for BB84), they correct errors and apply privacy amplification to erase whatever Eve might know. Above it, they abort.

BB84 simulation

Drag the Eve slider up and watch the error rate rise. With many photons, QBER ≈ 25% × the fraction of photons intercepted.

Photons Eve intercepts: 0% Channel noise: 0%

How much key survives?

Not every sifted bit becomes key. Two costs are paid from it:

Error correction (for example Cascade or LDPC codes) leaks about f · h(Q) bits per bit over the public channel, where h is the binary entropy and f ≥ 1 is the code's inefficiency.
Privacy amplification hashes the result down by about h(Q) more, removing everything Eve could know.

r = 1 − f·h(Q) − h(Q) h(x) = −x log₂x − (1−x) log₂(1−x)

With perfect error correction (f = 1) this is the Shor–Preskill result (2000), r = 1 − 2h(Q), which hits zero at Q ≈ 11% — the abort threshold used earlier.

Secret key fraction

Fraction of sifted bits that become secret key, for an ideal single-photon BB84 link (asymptotic limit).

QBER: 3.0% Error-correction inefficiency f: 1.16

Finite-key effects. These formulas assume infinitely long runs. Real systems estimate QBER from a finite sample, so they must subtract a statistical safety margin. Short sessions can yield zero key even at low QBER; vendors therefore process blocks of millions of detections at a time.

The hardware

Part	Common choices	Notes
Source	Attenuated laser pulses with decoy states; entangled photon pairs from nonlinear crystals (SPDC)	True single-photon sources exist in labs but are not yet practical. Lasers sometimes emit 2+ photons — hence decoy states.
Encoding	Polarization, phase, time-bin; amplitude and quadrature for CV-QKD	Phase and time-bin are robust in fiber, where polarization drifts; polarization suits free space and satellites.
Channel	Telecom fiber at 1550 nm; free-space optics	Can share fiber with classical data using wavelength multiplexing, but Raman scattering from strong classical light adds noise.
Detectors	InGaAs avalanche photodiodes; superconducting nanowire detectors (SNSPDs)	SNSPDs reach very high efficiency and low noise but need cryogenic cooling; they enable the longest links and the highest rates.
Classical side	FPGA post-processing, authenticated channel, key management system	Often the bottleneck for key rate, and where much of the software attack surface lies.

Typical field systems deliver key rates from kilobits to a few megabits per second over metropolitan distances (tens of km); laboratory records reach tens of megabits per second over about 10 km.

Quantum hacking

QKD proofs assume devices behave exactly as modeled. Attacks target the gap between model and hardware:

Attack	How it works	Countermeasure
Photon-number splitting	Eve keeps one photon from multi-photon pulses and lets the rest through	Decoy states
Detector blinding	Bright light forces detectors into a classical mode Eve can control; demonstrated against commercial systems in 2010	Detector monitoring; MDI-QKD removes the detectors from the trust boundary
Time-shift	Exploits efficiency mismatch between detectors at different arrival times	Randomized timing, calibration, MDI-QKD
Trojan horse	Eve shines light into Alice's device and reads the reflected modulator setting	Optical isolators, filters, power monitors
Laser seeding, phase remapping	Manipulate the source or modulator from outside	Isolation, source monitoring, security certification (ISO/IEC 23837)

Each discovered attack has been patched, and the protocol variants in the next section aim to remove whole classes of them. The lesson matches classical cryptography: proofs protect the model, engineering protects the device.

Protocols after BB84

Protocol	Idea	What it solves
Decoy-state	Randomly mix in "decoy" pulses of different intensities	Defeats photon-number-splitting attacks when a laser occasionally emits several photons. Standard in commercial systems.
Six-state (1998)	Adds a third basis to BB84	More symmetric error statistics; tolerates a QBER up to about 12.6%, at the cost of a lower sifting rate.
BBM92 (1992)	Entanglement-based version of BB84; the source can sit in the middle	The source need not be trusted; used in satellite experiments.
COW, DPS	Encode in pulse timing or phase differences between neighboring pulses	Simple, robust hardware for fiber; used in commercial products.
E91 (Ekert, 1991)	Uses entangled photon pairs; tests Bell's inequality	Detects eavesdropping through the degree of Bell violation — the basis for device-independent QKD.
MDI-QKD	Alice and Bob both send photons to an untrusted middle station that measures	Removes all detector attacks — the biggest weakness in practice.
Twin-Field (TF-QKD)	Interferes both parties' optical fields at a middle station	Key rate falls as √η instead of η, beating the PLOB bound; experiments have reached about 1,000 km of fiber.
CV-QKD	Encodes in the amplitude and phase of light, measured with coherent detection	Uses standard telecom components, cheaper, but shorter range.
DI-QKD	Proves security from Bell statistics alone, without trusting devices	The highest level of assurance; still lab-only with very low rates.

Distance is the enemy

Optical fiber loses about 0.2 dB per km — half the photons every 15 km. Quantum signals cannot be amplified like ordinary ones, because amplifying means copying. So the key rate falls exponentially with distance.

Key rate vs distance

Idealized model, 0.2 dB/km loss, relative rate per pulse (log scale). Drag to read values at each distance.

Distance 100 km

The PLOB bound (Pirandola et al., 2017) is the maximum any point-to-point protocol without repeaters can reach. TF-QKD beats it thanks to the middle station, but truly long distances still need quantum repeaters — a technology still in research.

QKD networks today

Beijing–Shanghai backbone (China, 2017): over 2,000 km of fiber, linked by a chain of trusted nodes.
Micius satellite (2016): distributed keys from orbit to the ground, and in 2017 enabled a quantum-key-encrypted video call between Beijing and Vienna.
EuroQCI: the European Union initiative to build quantum communication infrastructure on the ground and in space.
Standards: ETSI (GS QKD group), ITU-T Y.3800 series, ISO/IEC 23837 on security evaluation of QKD devices.

What is a trusted node? When a link is too long, keys are created over short segments and "relayed" through nodes. At each node the key exists in classical form — so the node must be physically protected and fully trusted. That is a big gap from the promise of "absolute security".

QRNG — the easier sibling

A quantum random number generator (QRNG) uses quantum effects to produce truly random numbers. It does not replace QKD or PQC, but it can supply entropy for key generation and already ships in some chips and phones.

Beyond key distribution

QKD only answers "how do two parties get a shared key?". Quantum cryptography has proposals for many other tasks, at very different levels of maturity:

Primitive	What it does	Maturity
QKD	Two parties grow a shared secret key	Commercial
QRNG	Random numbers from quantum measurement	Commercial
Certified randomness	A remote quantum computer proves its output is fresh randomness	First demo 2025
Quantum digital signatures	Signatures whose unforgeability rests on physics	Lab demos
Quantum secret sharing	Split a secret so only enough parties together can recover it	Lab demos
Quantum secure direct communication	Send the message itself over the quantum channel, with no key step	Lab demos
Blind quantum computing	Run a computation on someone else's quantum computer without revealing it	Lab demos
Quantum money	Banknotes that cannot be counterfeited because states cannot be copied	Theory

Quantum random number generators

A QRNG measures a quantum process — a photon at a beam splitter, vacuum noise, photon arrival times — and turns the outcomes into random bits. It is the most widely deployed piece of QKC: small chips exist, and some phones (for example Samsung's Galaxy Quantum models in Korea) include one. It does not replace QKD or PQC, but it can feed both with good entropy.

Quantum digital signatures

Proposed by Gottesman and Chuang in 2001. The signer distributes quantum "public keys"; because they cannot be copied, recipients can check a signature and forward it without forging. Current schemes sign only short messages at low rates, and keys are single-use — so for now PQC signatures (ML-DSA, SLH-DSA) are the practical choice.

Quantum secret sharing

Introduced by Hillery, Bužek and Berthiaume in 1999 using entangled states: a dealer splits a secret among several parties so that no subset below a threshold learns anything, and cheating participants are detectable.

Quantum secure direct communication

QSDC, proposed from 2002, sends the message directly over the quantum channel and checks for eavesdropping before any information leaks. It skips the "make a key, then encrypt" step, but needs quantum memory or careful block-by-block checks and is still experimental.

Blind and verifiable quantum computing

Broadbent, Fitzsimons and Kashefi (2009) showed that a client able to prepare simple quantum states can run a computation on a remote quantum server while hiding the input, the algorithm and the output — the quantum version of computing on encrypted data.

Quantum money

Stephen Wiesner's idea from around 1970 (published 1983): banknotes carrying photons in secret bases, uncopyable thanks to no-cloning. It was never practical — quantum states decay quickly — but the "conjugate coding" behind it directly inspired BB84.

QKC toolkit explorer

Pick a primitive to see its security basis, what it needs, and what to use today instead.

What quantum physics cannot secure

Quantum cryptography is not magic. Some tasks were proven impossible to secure unconditionally, even with quantum states:

Task	Result
Bit commitment	Proven impossible unconditionally by Mayers and by Lo and Chau (1997). Possible only with extra assumptions such as limited or noisy quantum storage.
Oblivious transfer, secure two-party computation	Also impossible unconditionally; the same bounded- or noisy-storage models rescue them.
Position-based cryptography	Proving where you are using only quantum signals is impossible in general (Buhrman et al., 2011) if attackers can share enough entanglement.
Authentication from nothing	Every QKC protocol needs an initial authenticated channel or shared secret. Quantum physics cannot bootstrap trust from zero.

QKC in a real system

A deployed quantum-cryptography link has several layers, and only the bottom one is quantum:

Quantum layer: photon source, fiber or free-space link, single-photon detectors; runs BB84, decoy-state or CV-QKD.
Post-processing: sifting, error estimation, error correction, privacy amplification — over an authenticated classical channel.
Key management: stores keys and hands them to applications; ETSI GS QKD 014 defines a standard key-delivery interface.
Application: VPN or link encryptors use the keys with AES, often mixed with a PQC key (hybrid) so the link survives if either one fails.

Hybrid is the norm. Many vendors and operators now combine QKD keys with ML-KEM keys through a key-derivation function: an attacker would need to break the quantum link and the PQC algorithm.

Chips, satellites and mobile

Early QKC hardware filled racks and needed stable, end-to-end optical fiber. Research is shrinking it:

Photonic chips: transmitters and receivers on silicon or indium-phosphide chips, aiming at mass production and lower cost. University of Bristol researchers, working with Nokia, demonstrated a chip-based protocol designed to tolerate noisy links, pointing toward handheld and wireless use.
Free-space and satellites: Micius proved ground-to-orbit links; several space agencies and the EU (EuroQCI) are planning QKD satellites to bridge distances fiber cannot.
Short-range handheld: prototypes let a phone-sized device exchange keys optically with a terminal, for example at an ATM.

Even so, QKC on everyday phones remains a research goal. For mass-market devices, PQC is what is actually shipping.

Limits of QKC

Limit	Why it matters
Still needs authentication	The classical channel must be authenticated or it falls to man-in-the-middle attacks. That needs a pre-shared key or digital signatures — usually PQC.
Range and trusted nodes	Each fiber hop is typically a few hundred km; beyond that you must trust intermediate nodes or use satellites.
Dedicated hardware	Needs photon sources, single-photon detectors, often dedicated fiber. It does not run over the Internet or ordinary routers.
Theory vs implementation	Real devices have been attacked: detector blinding, timing exploits, injected back-light.
Denial of service	Simply disturbing the line raises QBER and the session aborts.

For these reasons, security agencies such as the NSA (US), NCSC (UK) and ANSSI (France) recommend prioritizing PQC for most systems, treating QKD and other QKC tools only as add-ons for specialized links.

Next chapterSummary and knowledge check

Side by side

	RSA and ECC	PQC	QKC (QKD)
Security basis	Factoring, discrete logarithms	Lattice, code and hash problems	Laws of quantum physics
Against quantum computers	Broken by Shor	Believed secure	Secure in theory
Hardware	Ordinary computers	Ordinary computers	Dedicated optical equipment
Reach	Global, over the Internet	Global, over the Internet	Point-to-point, limited range
Digital signatures	Yes	Yes	No, key creation only
Cost	Low	Low, mostly software updates	High
Best fit	Legacy systems, being phased out	The default for most systems	Very high-value links between fixed sites

PQC and QKC complement rather than exclude each other: QKD needs PQC for authentication, and PQC is the practical path to protecting the Internet at scale.

All three create something easy to do with the key and extremely hard to undo without it. RSA and PQC put their trust in mathematics, QKC puts it in physics — and all three are only secure when implemented correctly.

What can go wrong?

Failure	Consequence
Textbook RSA	Deterministic encryption, guessable messages. Use RSA-OAEP.
Weak randomness	Repeated or predictable key-generation values expose private keys.
Side channels	Timing, power, cache or fault behavior leak secrets even when the math is sound.
ECDSA nonce reuse	Two signatures with the same nonce are enough to compute the private signing key.
No key verification	Without certificates and identity checks, an attacker substitutes their own public key.
Quantum computers	Threaten both RSA and common ECC; PQC rests on different assumptions.
People and operations	Stolen devices, exposed backups, poor access control, lost private keys.

Don't roll your own crypto. Use reviewed libraries, standard protocols, supported parameters, secure key storage and a plan for moving to PQC.

Knowledge check

Sources and further reading

RFC 8017 — PKCS #1: RSA, including OAEP and PSS
NIST FIPS 186-5 — Digital Signature Standard, RSA and elliptic-curve signatures
NIST SP 800-56A Rev. 3, discrete-log key establishment
RFC 7748 — X25519 and X448
RFC 8032 — EdDSA
RFC 8446 — TLS 1.3
FIPS 203 — ML-KEM, FIPS 204 — ML-DSA, FIPS 205 — SLH-DSA
NIST Post-Quantum Cryptography
NIST IR 8547 (draft) — Transition to PQC Standards
EU — Coordinated implementation roadmap for PQC
NIST SP 800-208 — Stateful hash-based signatures
ETSI — Quantum Key Distribution
NCSC — Quantum security technologies

Educational material, not a substitute for a cryptographic design review. Standards and guidance evolve; check current versions before deploying.