PQC

Post-Quantum Computing & SSD Security

A working page tracking the post-quantum cryptography (PQC) transition as it applies to SSDs and other storage controllers. Fill in with spec details and silicon specifics as they land.

Why This Matters for Storage (the threat model)

Two quantum algorithms matter here, and they hit storage crypto very differently:

• Shor's algorithm breaks RSA, ECC/ECDSA, and Diffie-Hellman in polynomial time on a sufficiently large fault-tolerant quantum computer — these are the asymmetric primitives. Not "weakened," effectively broken.
• Grover's algorithm gives only a quadratic speedup against symmetric primitives (AES) and hash functions. It halves the effective security level, so AES-256 degrades to roughly AES-128-equivalent quantum security — still considered safe. AES-128 degrading to ~64-bit equivalent is the one that becomes marginal.

The practical consequence: an SSD's bulk media encryption (typically AES-256-XTS under TCG Opal / Enterprise SSC) is largely fine as-is. The exposure is everywhere the drive uses asymmetric crypto:

• TCG Opal / Enterprise SSC Admin SP authentication and PKI-based credential provisioning
• Firmware signing / secure boot — the signature chain that proves controller firmware is authentic
• Key wrapping / key exchange with external key managers (KMIP-based)
• NVMe-oF fabric security — TLS 1.3 session setup, DH-HMAC-CHAP authentication
• Secure messaging / attestation between drive, host, and BMC

Firmware signing is the sharpest edge: if an attacker can forge a signature on a firmware image (via a future quantum computer, using signatures/keys harvested today), they get persistent control of the drive. That's the scenario both NIST and vendors point to.

The relevant risk model is "harvest now, decrypt later" (HNDL) — adversaries capture encrypted traffic, key-exchange transcripts, or signed artifacts today and hold them until a cryptographically relevant quantum computer exists. This matters most for data/keys with long shelf life: enterprise and archival drives are commonly deployed 5–10+ years, so anything protected only by classical asymmetric crypto today is exposed retroactively. Some 2025 research suggests breaking RSA-2048 may need fewer physical qubits than earlier estimates assumed, which compresses (but doesn't eliminate) the assumed safety margin.

NIST PQC Standards (finalized August 2024)

Algorithm	FIPS	Type	Basis	Typical role
ML-KEM (Kyber)	FIPS 203	Key encapsulation	Lattice (Module-LWE)	Key exchange / session establishment
ML-DSA (Dilithium)	FIPS 204	Digital signature	Lattice	General-purpose signing (firmware, certs)
SLH-DSA (SPHINCS+)	FIPS 205	Digital signature	Hash-based	Conservative/backup signature scheme
FN-DSA (Falcon)	pending	Digital signature	Lattice (NTRU)	Compact-signature alternative to ML-DSA

ML-KEM and ML-DSA are the two actually showing up in shipping storage silicon so far (see below).

CNSA 2.0 (NSA) Compliance Timeline

• Jan 1, 2027 — new federal system deployments must comply with CNSA 2.0
• Dec 31, 2030 — phase-out deadline for equipment/services that can't support CNSA 2.0
• Dec 31, 2031 — mandatory use of CNSA 2.0 algorithms (with limited exceptions)
• 2035 — full migration target under Executive Orders 14144 and 14306

CNSA 2.0's approved set is exactly ML-KEM (key exchange), ML-DSA (signatures), and SLH-DSA (alternative signatures) — same trio as the NIST FIPS standards above. The Jan 2027 deadline is already driving near-term enterprise/federal storage procurement requirements.

Industry Status (as of August 2026)

NVMe 2.4 base spec — ratified July 31, 2026, published Aug 4, 2026. Adds native support for ML-KEM / ML-DSA / SLH-DSA at the protocol level. This required expanding NVMe field sizes to carry much larger key/signature material — e.g., an ML-KEM-768 public key is 1,184 bytes vs. 32 bytes for classical X25519. The same spec wave also bundled SSD virtualization support and IOPS/bandwidth rate limiting, which is unrelated to PQC but worth remembering when trying to place feature attribution later. Early silicon: Kioxia CM10 series (sampling July 2026), ScaleFlux FC6116 controllers. Typical hardware lag from spec ratification to validated silicon is 12–18 months, so broad availability is more like late 2027.

Novachips P2-series SSDs (announced Jan 2026) — ML-KEM-1024 + ML-DSA-87, CNSA 2.0 compliant, dedicated onboard PQC processor so key establishment/signing doesn't burn host CPU cycles. Vendor quote: PQC operations take "5–20x longer" than the classical asymmetric operations they replace, which is presumably why this is offloaded rather than left to the main controller cores. Ships as 2.5" SATA, U.2/M.2 PCIe, and USB, 500 GB–16 TB, MIL-STD-810G rugged variants; FIPS 140-3 and Common Criteria certification pending at announcement.

Western Digital Ultrastar DC HC6100 UltraSMR (May 2026, HDD not SSD, but same controller-security architecture pattern) — ML-DSA-87 for secure boot, firmware signing, and secure messaging, via an integrated HSM. Uses dual-signing / hybrid certificates so drives can verify both classical and PQC signatures during migration, and the change is transparent to the host (no driver/software changes needed). Useful as a reference architecture even though it's spinning media, since the firmware-signing threat model is identical for SSD controllers.

TCG — TPM 2.0 spec has already integrated PQC algorithms; relevant wherever a storage security architecture roots trust in a platform TPM rather than (or in addition to) the drive's own Admin SP. Unclear yet whether TCG Opal/Enterprise SSC gets its own explicit PQC revision or whether NVMe 2.4's in-band mechanisms end up superseding that layer for NVMe drives specifically — open question, see below.

Performance & Implementation Considerations

• Key/signature size growth is the main protocol-level pain point. ML-KEM-768 public keys (~1,184 B) vs. X25519 (~32 B) is roughly 37x; ML-DSA-87 signatures (~4.6 KB) vs. ECDSA (~64–72 B) is two orders of magnitude larger. This is why NVMe 2.4 needed field-size changes rather than a drop-in algorithm swap.
• Compute overhead pushes toward dedicated crypto engines. The 5–20x slower key establishment/signing that Novachips reports is a strong argument for a purpose-built PQC block on the controller rather than spending general-purpose controller cycles — echoes the ECC/LDPC dedicated-engine pattern already used for NAND error correction (see ssd-controller-architecture).
• Crypto-agility / hybrid mode is the transition strategy everyone is using. Both WD and the CNSA 2.0 guidance lean on dual classical+PQC signing/handshakes so fielded drives can verify either during the multi-year migration window, rather than a hard cutover.
• Bulk media encryption doesn't need to move. AES-256-XTS (or equivalent) for the actual data-at-rest encryption is unaffected by this transition — the entire scope here is the asymmetric layer (auth, key wrap, signing, transport).
• Where this could show up as a new "stage" in the bottleneck-model sense (see ssd-controller-architecture): PQC operations are session/boot-time costs (unlock latency, firmware verification at boot, key-exchange at connection setup), not a sustained throughput bottleneck — worth modeling as a one-time latency term rather than a bandwidth stage.

Open Questions / Next Steps

• [ ] Pull the actual NVMe 2.4 technical proposal once broadly available for exact field-level changes to Security Send/Receive and DH-HMAC-CHAP negotiation.
• [ ] Determine whether TCG Opal/Enterprise SSC gets an explicit PQC revision, or whether NVMe 2.4's in-band mechanisms supersede that layer for NVMe drives.
• [ ] Quantify PQC unlock/boot-time latency overhead on real silicon once Kioxia CM10 / ScaleFlux FC6116 specs are public, and compare against the 5–20x figure Novachips cites.
• [ ] Track how SATA/legacy-interface drives (no NVMe 2.4 path) are expected to reach CNSA 2.0 compliance ahead of the Jan 1, 2027 federal deadline.
• [ ] Note FN-DSA (Falcon) status once finalized — currently pending, would round out the CNSA 2.0 signature options.