Migrating To Post Quantum Cryptography

Migrating to Post-Quantum Cryptography

Scope and Authorization: This skill describes defensive cryptographic-migration engineering on systems you own or operate. Cryptographic discovery scanning can touch sensitive key material and production traffic — run inventory tooling only with authorization and in line with your organization's change-management and data-handling policies.

Overview

A cryptographically relevant quantum computer (CRQC) running Shor's algorithm will break the public-key cryptography that secures almost all of today's communications and signatures: RSA, finite-field and elliptic-curve Diffie-Hellman (DH/ECDH), and ECDSA. Symmetric primitives (AES) and hashes (SHA-2/3) are only weakened (Grover gives a quadratic speedup, mitigated by larger key/output sizes), but asymmetric algorithms are catastrophically broken. The most urgent threat is harvest-now, decrypt-later (HNDL): adversaries capturing encrypted traffic today to decrypt once a CRQC exists, which puts long-lived secrets (health records, state secrets, intellectual property, root-of-trust keys) at risk now.

On 13 August 2024 NIST finalized the first post-quantum standards: FIPS 203 (ML-KEM, Module-Lattice KEM, formerly CRYSTALS-Kyber) for key establishment, FIPS 204 (ML-DSA, Module-Lattice digital signatures, formerly CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, the stateless hash-based signature scheme SPHINCS+). The migration playbook (NIST SP 1800-38, Migration to Post-Quantum Cryptography) is: (1) build a cryptographic inventory / CBOM, (2) prioritize by HNDL exposure and crypto-agility, (3) deploy hybrid schemes (a classical algorithm AND a PQC algorithm combined, e.g. X25519MLKEM768) so a break in either leg does not compromise the session, and (4) re-key and rotate.

This skill maps to ATT&CK T1573 – Encrypted Channel: the same cryptographic channels adversaries abuse for stealthy C2 are the channels defenders must make quantum-resistant; understanding the algorithms in use is foundational to both attack detection and defensive migration. The NIST CSF outcome is PR.DS-02 (data-in-transit protection) — and by extension data-at-rest for HNDL-sensitive stores.

When to Use

• When building an enterprise cryptographic inventory / Cryptography Bill of Materials (CBOM) for quantum-readiness.
• When prioritizing which systems must migrate first based on data lifetime and HNDL exposure.
• When enabling hybrid post-quantum key exchange (X25519MLKEM768) on TLS endpoints, VPNs, or SSH.
• When issuing PQC or hybrid certificates and testing PQC signature verification.
• When evaluating crypto-agility — the ability to swap algorithms without re-architecting applications.

Prerequisites

• OpenSSL 3.5.0 or later, which ships native ML-KEM, ML-DSA, and SLH-DSA support:

  openssl version            # expect 3.5.0+
  openssl list -kem-algorithms | grep -i mlkem
  openssl list -signature-algorithms | grep -i mldsa

• For OpenSSL 3.0–3.4, the Open Quantum Safe oqs-provider plus liboqs:

  git clone https://github.com/open-quantum-safe/liboqs && \
    cmake -S liboqs -B liboqs/build && cmake --build liboqs/build && \
    sudo cmake --install liboqs/build
  git clone https://github.com/open-quantum-safe/oqs-provider && \
    cmake -S oqs-provider -B oqs-provider/_build && \
    cmake --build oqs-provider/_build && \
    sudo cmake --install oqs-provider/_build

• Python 3.8+ for the inventory helper:

  python3 -m pip install cryptography

• (Optional) A CBOM generator: CycloneDX cdxgen, or cbomkit-theia for container/directory crypto discovery.

Objectives

• Produce a cryptographic inventory (CBOM) of algorithms, key sizes, certificates, and protocols in use.
• Classify assets by quantum vulnerability and HNDL exposure and prioritize migration.
• Stand up and verify hybrid X25519MLKEM768 key exchange on a TLS endpoint.
• Generate ML-KEM and ML-DSA keys and a PQC/hybrid certificate, and verify signatures.
• Establish a crypto-agility baseline and a re-keying / rotation plan.

MITRE ATT&CK Mapping

Workflow

1. Confirm PQC algorithm availability

openssl version
# List quantum-safe KEMs and signatures available in this OpenSSL build
openssl list -kem-algorithms | grep -Ei 'mlkem|kyber'
openssl list -signature-algorithms | grep -Ei 'mldsa|dilithium|slhdsa|sphincs'
openssl list -tls-groups 2>/dev/null | grep -Ei 'mlkem'

If using oqs-provider on OpenSSL 3.0–3.4, activate it in openssl.cnf:

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect
[default_sect]
activate = 1
[oqsprovider_sect]
activate = 1

2. Build a cryptographic inventory (CBOM)

Generate a CycloneDX CBOM from a code repo or container with cbomkit-theia / cdxgen:

# Directory / container image crypto discovery
cbomkit-theia dir ./myapp --output cbom.json
# or with cdxgen (Java keystores, certs, source-level algorithms)
cdxgen -t java --include-crypto -o cbom.json ./myapp

Enumerate TLS algorithms and certificate signature schemes across live endpoints with the helper agent.py scan (below), and the public-key strength of any certificate:

openssl x509 -in server.crt -noout -text | grep -E 'Signature Algorithm|Public Key'