Post-Quantum Cryptography, Eight Years Later: Revisiting My Master's Thesis
In 2018 I wrote a master's thesis on the state of post-quantum cryptography and built simulators for McEliece and Niederreiter. Here's what the field looks like now - and what actually changed.
In December 2018 I finished my master's thesis: "State-of-the-art of post-quantum cryptography and McEliece/Niederreiter cryptosystem simulators" - a survey of post-quantum cryptography (PQC) and a practical simulator for two code-based cryptosystems.
At the time, NIST's post-quantum standardization competition was in full swing. Round 1 had closed with 69 candidate algorithms. SIKE looked like a serious contender. Google was experimenting with NewHope in Chrome. McEliece was the old survivor everyone respected but nobody wanted to deploy because of key sizes.
Eight years later, the race didn't end - it produced standards. Some of the algorithms I wrote about are now FIPS documents. Others were broken on a laptop in an hour.
This post isn't a summary of the thesis. It's a look at what I was trying to understand back then, what I built to learn it, and how the world moved since.
What the thesis was trying to do
The core question was simple, even if the math wasn't: RSA and elliptic-curve cryptography will not survive Shor's algorithm on a large enough quantum computer. Symmetric crypto gets weakened by Grover but can compensate with longer keys. Public-key crypto needs replacement algorithms based on different hard problems.
The thesis walked through:
- Why PQC exists - Shor, Grover, the BQP complexity class, and the "harvest now, decrypt later" threat (Tanja Lange was already warning that adversaries could store encrypted traffic today and decrypt it once quantum hardware matures).
- The algorithm families - lattice-based, code-based, multivariate, hash-based, isogeny-based, and others.
- The NIST competition landscape - who submitted what, KAT analysis, key sizes, security claims as of August 2018.
- Applied context - hybrid TLS suites, blockchain implications, IoT constraints, embedded implementations.
The conclusion was cautious optimism: lots of candidates, lots of investment, but standardization would decide what actually ships - and McEliece-style schemes would remain academically interesting long before they become default infrastructure.
That part aged well.
The simulator: learning code-based crypto by clicking
Theory is fine. I wanted to see a post-quantum cryptosystem work.
The practical component was a Java/JavaFX desktop application that simulates the classic McEliece and Niederreiter cryptosystems step by step - not production crypto, but an interactive walkthrough of how code-based public-key encryption actually operates.
What it demonstrated
McEliece (1978) hides a structured linear code behind random transformations. The public key looks like a generic code; the private key knows the fast decoding structure. Encryption adds a deliberate error vector - only someone who knows the code can correct it.
Niederreiter (1986) is the dual variant: work with parity-check matrices instead of generator matrices, encode messages as low-weight vectors, and decode via syndrome computation. Faster encryption in some configurations, and it supports signatures - something classic McEliece doesn't do cleanly.
The simulator implemented both with two code types:
| Code type | Purpose in the app |
|---|---|
| Hamming(7,4) | Small, readable grids - every matrix operation visible, syndrome decoding explained cell by cell |
| Binary Goppa codes | Closer to real McEliece parameters - Patterson's algorithm for efficient syndrome decoding without building full lookup tables |
For Goppa codes I adapted Elena Klintsevich's Patterson implementation from FlexiProvider, broken into visual steps so you could follow the math instead of trusting a black box.
The app also compared key generation time and key sizes across parameter sets - the moment where code-based cryptography stops being abstract and starts being an engineering problem. A secure McEliece public key isn't a few hundred bytes. It's megabytes. That tradeoff was obvious in 2018. It's still obvious in 2026.
Delivered as a standalone .jar with a bundled JRE for Windows. Very 2018. Still useful if you want to understand why Classic McEliece has enormous keys and why lattice schemes eventually won the deployment argument.
What I got right in 2018
The framing. PQC isn't about quantum computers existing tomorrow. It's about migration timelines, long-lived secrets, and the risk of storing ciphertext today that becomes readable later. That hasn't changed - if anything, it's more urgent.
The category map. Lattice, code, hash, multivariate - the families I surveyed are still the vocabulary. NIST's final standards came from three of them.
Hybrid cryptography as the transition path. The thesis discussed classical + post-quantum combinations in TLS (NewHope + X25519 in Chrome Canary, OpenQuantumSafe, wolfSSL). That's exactly how production migration works now - not a hard cutover, but dual algorithms until confidence and interoperability catch up.
Key size as a first-class constraint. Chapter 3 parsed NIST Known Answer Test (KAT) files from round-1 candidates and plotted secret and public key sizes across hundreds of parameter sets. The pattern was impossible to miss:
Blue points are secret keys, orange points are public keys. Each dot is a specific algorithm configuration. The Y axis is logarithmic — so a step that looks small on the chart can still mean a 10× or 100× difference in actual bytes. What looks like a gentle curve is often a massive gap in practice.
The shape is almost parabolic: the smaller the secret key, the larger the public key tends to be, and vice versa. On the left, schemes carry megabyte-scale secret material while public keys stay comparatively smaller. On the right, tiny secret keys come paired with public keys that jump back up — sometimes to hundreds of kilobytes or more. There is no free lunch in key material; families just shift the cost between holder and sender.
That tradeoff is why code-based and some multivariate schemes clustered at the extremes, while lattice candidates like Kyber landed in a middle band small enough for TLS handshakes. IoT and embedded systems don't forgive megabyte keys on either side. The chart predicted the deployment outcome before NIST had picked winners.
McEliece's durability as math, not as default infrastructure. The thesis treated code-based crypto as proven against quantum attacks with parameter choices that were already under active cryptanalysis - and noted that Niederreiter improved on McEliece for performance. Classic McEliece is still in NIST's orbit for standardization as a backup KEM precisely because the math has decades of scrutiny - even though nobody pretends the keys are convenient.
What changed - the news since 2018
This is where the thesis becomes a time capsule.
NIST finished. Finally.
In August 2024, NIST published three finalized standards:
| Standard | Algorithm | Role | 2018 name |
|---|---|---|---|
| FIPS 203 | ML-KEM | Key encapsulation | CRYSTALS-Kyber |
| FIPS 204 | ML-DSA | Digital signatures | CRYSTALS-Dilithium |
| FIPS 205 | SLH-DSA | Hash-based signatures (backup) | SPHINCS+ |
These are no longer competition entries. They're Federal Information Processing Standards - the bureaucratic signal that procurement, compliance, and vendor roadmaps can move.
A FALCON-based signature standard (FIPS 206) followed. In 2025, NIST selected HQC as an additional code-based KEM for standardization - a second family alongside ML-KEM, not a replacement.
In 2018 my thesis listed dozens of candidates. In 2026 the answer for most deployments is: ML-KEM for key exchange, ML-DSA for signatures, SLH-DSA if you want hash-based backup. Everything else is niche, legacy migration, or research.
The isogeny dream collapsed
My thesis dedicated space to SIDH / SIKE - supersingular isogeny Diffie-Hellman - as one of the elegant alternatives with small keys and serious academic backing. SIKE even advanced to NIST's fourth round.
In July 2022, Castryck and Decru published a classical attack that recovered SIKE private keys in about an hour on a single CPU core.
SIKE was withdrawn. SIDH as widely deployed was dead. The thesis's isogeny section wasn't wrong about the mathematics being interesting - it was wrong about stability under cryptanalysis pressure, which is the only metric that matters for standards.
That's the biggest delta between 2018 and now: one full family went from finalist to broken on commodity hardware.
Migration got a deadline
NIST IR 8547 (2024) answers the question the 2018 thesis couldn't: when do legacy algorithms actually go away?
Rough timeline:
- After 2030 - RSA, ECDH, ECDSA, DSA, and finite-field DH become deprecated. Continued use requires documented risk acceptance.
- After 2035 - those algorithms become disallowed, including in legacy systems.
Important detail IR 8547 makes explicit: bumping RSA from 2048 to 4096 does not buy migration time. Shor breaks integer factorization regardless of key length. The path forward is ML-KEM and ML-DSA, not bigger classical keys.
Hybrid schemes (ML-KEM combined with X25519, per RFC 9496 and related work) are the bridge - exactly the pattern the thesis described experimentally, now with standards numbers attached.
Code-based crypto: vindicated, still awkward
Classic McEliece - the modern descendant of what I simulated - remains under consideration as a backup KEM with tiny ciphertexts and enormous public keys. The simulator's key-size comparisons weren't pessimism. They were the product spec.
HQC, another code-based scheme, was selected for standardization in 2025. Code-based cryptography didn't win the default slot, but it didn't disappear either. The thesis treated it as a durable fallback family. NIST's 2025 decisions agree.
The ecosystem matured
In 2018 I cited OpenQuantumSafe, liboqs, hybrid Chrome experiments, and EU-funded projects like PQCRYPTO and SAFECrypto.
In 2026:
- liboqs and major TLS stacks support ML-KEM and ML-DSA.
- Cloud providers and browsers are rolling out post-quantum TLS in production, not Canary experiments.
- "PQC" moved from conference slides to vendor datasheets and RFP requirements.
The thesis predicted the shape. It didn't predict the speed - NIST's process took longer than optimistic 2018 timelines suggested, but the direction was always clear.
What I'd write differently today
If I were starting the thesis in 2026, I'd spend less time cataloging 69 candidates and more time on:
- Migration mechanics - certificate chains, protocol negotiation, hybrid handshakes, HSM support, breaking changes in PKI.
- Cryptanalysis velocity - SIKE's death is a lesson that "NIST finalist" ≠ "safe forever" until years of public scrutiny pass.
- Operational PQC - where RSA hides in your stack that isn't TLS (code signing, email, document encryption, VPNs, firmware update chains).
- Policy - GDPR, long-retention medical records, and government "store now, decrypt later" programs as drivers, not side notes.
The simulator would probably still be McEliece and Niederreiter. There's no better way to understand why lattice keys won on size than watching a Goppa code encode a message with deliberate errors.
Closing
My 2018 thesis captured a field in motion: NIST round 1, dozens of families, hybrid experiments, and the quiet understanding that RSA's clock was running.
Eight years later, the clock has numbers on it - 2030, 2035 - and the algorithms have names in FIPS documents. Some candidates became standards. One finalist was broken on a laptop. The McEliece simulator still explains the tradeoffs the standards process couldn't eliminate, only choose between.
Post-quantum cryptography stopped being "future research" somewhere between Kyber's selection and ML-KEM's publication. For someone who wrote about it when the answer was still a spreadsheet of 69 submissions, watching it become infrastructure is the satisfying part - even if I'd prefer fewer megabyte public keys in the backup column.
If you're entering the field now, you don't need a thesis-length survey. You need ML-KEM, ML-DSA, migration planning, and enough code-based intuition to understand why Classic McEliece keys come on a truck. The simulator was my way of building that intuition. The standards are everyone else's way of being forced to use it.
Further reading