Skip to main content
Home/Topics/Post-Quantum Cryptography

Topic · my POV

Post-quantum cryptography, from where I sit

A working researcher's perspective on PQC standards, ICS migration constraints, smartcard HSM limits, and what to deploy in 2026 that still works in 2035.

What this page is

Post-quantum cryptography is the new fact of life for anyone who builds systems that need to keep secrets longer than 10 years. This page is my standing perspective on it — updated when my views shift, not when search-engine recency demands. If you want the verbatim research, the deep-dives are downstream.

The honest CRQC timeline

NIST CNSA 2.0 calls for PQC adoption in critical infrastructure by 2030–2033. That is a goal, not a forecast. Most utilities cannot complete a single firmware-rotation cycle in that window. The honest planning question is what we deploy in 2026 that is still safe in 2035, not whether we can hit a 2030 milestone. Harvest-now-decrypt-later is the lever that resolves the timing argument: even if a CRQC is 15 years away, the encrypted traffic adversaries are storing today decrypts the day it arrives.

What the NIST standards actually buy you

Three families to know:

  • ML-KEM (Kyber) — module-lattice key encapsulation. Standardized in FIPS 203. Fast, small ciphertexts, lattice-hardness assumption.
  • ML-DSA (Dilithium) — module-lattice digital signatures. FIPS 204. Compact enough for many constrained-device flows.
  • SLH-DSA (SPHINCS+) — hash-based signatures. FIPS 205. Larger signatures, but conservative cryptographic assumptions (just hash security).

Most production deployments will use Kyber+Dilithium for the common path and SPHINCS+ as the long-term-archive signature where signature size doesn't matter and crypto-agility costs more than hash-output bytes.

Why ICS migration is harder than TLS migration

TLS migration is a software problem with a fast feedback loop: cert authorities, browser vendors, and library maintainers can ship the new primitive in months. ICS migration is a hardware-and-procurement problem stretched across 20-year asset lifecycles, regulated change windows, and vendors who cannot patch firmware in field. The threat models look similar; the implementation timelines are an order of magnitude apart. This is why the IETF LAKE working group's PQ-EDHOC matters — it tries to land PQC at the constrained-device layer where firmware rotation is hardest.

The HSM problem

Hardware Security Modules are sized for RSA-2048 and ECDSA-P256. Kyber-768 and Dilithium2 don't fit the same memory and timing budgets cleanly. Smartcard-class HSMs need careful implementation work; many existing HSMs need replacement, not firmware update. This is the silent budget item nobody includes in PQC migration plans.

My research on this topic

My commentary on this topic

Glossary terms relevant to this topic

From the site glossary: CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+, Falcon, ML-KEM, ML-DSA, SLH-DSA, Harvest-Now-Decrypt-Later, Lattice-Based Cryptography, PQ-EDHOC, Hybrid Cryptography, Crypto-Agility, HSM.

What I'm reading on this topic

  • NIST FIPS 203 / 204 / 205 (the standards themselves — read them at least once)
  • IETF LAKE working group drafts on PQ-EDHOC
  • NSA CNSA 2.0 timeline document
  • Open Quantum Safe (liboqs) implementation notes
  • ENISA "Post-Quantum Cryptography: Current State and Quantum Mitigation"

Talk to me about this

Journalists: press kit with ready-to-quote paragraphs.
Conference programmers: speaking page — this is one of my four keynote topics.
Editors: editorial record — I review papers in this area.
Direct: shujaatali@ieee.org with subject [PQC].