Foundation · v0.2.0 · Reference

Glossary.

Forty-plus post-quantum cryptography terms in plain language and technical definition. Alphabetical. Cross-referenced.

Each entry has a plain-language definition, a technical elaboration, the primary source authority, and "see also" cross-references. Every term carries an anchor so you can deep-link to it from briefings, the whitepaper, or your own documentation. The glossary is reviewed quarterly; the standards baseline (FIPS 203/204/205) is stable.

Acronym quick-reference
Acronym	Full term
CA	Certificate Authority
CBOM	Cryptographic Bill of Materials
CISA	Cybersecurity and Infrastructure Security Agency
CNSA 2.0	Commercial National Security Algorithm Suite, version 2.0
CRQC	Cryptographically Relevant Quantum Computer
ECDH(E)	Elliptic Curve Diffie–Hellman (Ephemeral)
ECDSA	Elliptic Curve Digital Signature Algorithm
FIPS	Federal Information Processing Standard
HNDL	Harvest Now, Decrypt Later
KDF	Key Derivation Function
KEM	Key Encapsulation Mechanism
ML-DSA	Module-Lattice Digital Signature Algorithm
ML-KEM	Module-Lattice Key Encapsulation Mechanism
MTU	Maximum Transmission Unit
NCCoE	National Cybersecurity Center of Excellence
NIST	National Institute of Standards and Technology
NSM-10	National Security Memorandum 10
OCSP	Online Certificate Status Protocol
OMB M-23-02	OMB Memorandum on Post-Quantum Cryptography
PFS	Perfect Forward Secrecy
PKI	Public Key Infrastructure
QCCPA	Quantum Computing Cybersecurity Preparedness Act
RSA	Rivest–Shamir–Adleman
SLH-DSA	Stateless Hash-Based Digital Signature Algorithm
SNDL	Store Now, Decrypt Later (synonymous with HNDL)
TLS	Transport Layer Security

AES Advanced Encryption Standard

The symmetric cipher used to encrypt the actual data flowing through TLS, IPsec, and most disk-encryption systems. Unlike RSA and ECC, AES is not directly broken by quantum computers — its effective security is only halved by Grover's algorithm.

AES-128 is weakened to roughly 64-bit effective security against a quantum adversary running Grover's algorithm, which is considered borderline and likely inadequate for long-lived secrets. AES-256 retains roughly 128-bit effective security, which is the operating-grade recommendation for a post-quantum future. The implication: a key-size uplift is generally sufficient for symmetric encryption; the public-key layer is where the algorithm change is required.

Source: FIPS 197 · NIST IR 8547

CA Certificate Authority

An entity that issues and revokes certificates, anchoring the trust hierarchy for TLS, code signing, and identity. In the PQC transition the CA layer is high-priority because root and intermediate CAs sign certificates with multi-year lifetimes.

Root CAs that sign with classical algorithms today are signing trust anchors that may need to remain valid past the CNSA 2.0 inflection. Public CAs and large enterprise PKIs are in the early stages of issuing PQC-capable certificates; the operational migration involves dual-cert or composite-cert approaches during the transition, and OCSP and CRL infrastructure must be updated in lockstep.

See also: PKI chain validation · OCSP · SLH-DSA

Source: IETF PKIX · NIST CSWP 39

CBOM Cryptographic Bill of Materials

A living register of every place cryptography is used in an organization's systems — the foundational artifact of crypto-agility. Without a CBOM, no meaningful migration prioritization is possible.

The CBOM should cover libraries, firmware, managed services, identity federation, code-signing pipelines, certificate stores, HSMs, and any third-party service that performs cryptographic operations on the organization's behalf. NIST CSWP 39 emphasizes that the CBOM must be under change control with a quarterly review cycle — a one-time snapshot becomes obsolete within a release cycle because libraries and vendor products update independently.

CISA Cybersecurity and Infrastructure Security Agency

The U.S. federal agency whose January 2026 product-category guidance converted PQC from a technical conversation into a procurement signal. Procurement teams now have an agency-backed framework for preferring PQC-capable products.

CISA's January 2026 Product Categories for Technologies That Use Post-Quantum Cryptography Standards identified initial-priority categories — cloud services, web software, networking hardware and software, and endpoint security — and is the document procurement officers cite when adding PQC readiness language to RFPs and contracts.

CNSA 2.0 Commercial National Security Algorithm Suite, version 2.0

The NSA's algorithm suite for National Security Systems. Mandates ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, on a phased timeline. The procurement signal for the federal market and the de facto signal for vendor roadmaps.

CNSA 2.0 milestones: PQC products widely available by January 2026, preferred by January 2027 for all NSS acquisitions, classical key-establishment algorithms disallowed by 2030, classical signatures disallowed by 2031, and full deprecation by 2035. Private-sector operators are not bound by CNSA 2.0 directly but are shaped by it through the vendor ecosystem.

See also: ML-KEM · ML-DSA · QCCPA · NSM-10

Source: NSA Cybersecurity Information Sheet — CNSA 2.0

Composite certificate

A single X.509 certificate that contains both a classical and a post-quantum signature. One of two leading approaches (alongside dual-cert) for transitional PKI deployment.

Composite-cert approaches reduce client-side complexity (one chain to validate) at the cost of certificate size and CA implementation maturity. As of 2026 the IETF and CA/Browser Forum drafts are active but not yet at final standards-track status, so production deployments tend to favor the composite approach in tightly-controlled internal PKIs and the dual-cert approach where coordination across CAs is required.

CRQC Cryptographically Relevant Quantum Computer

A quantum computer powerful enough to run Shor's algorithm against widely deployed public-key systems — the threshold at which RSA and elliptic-curve cryptography are broken at scale.

No credible enterprise should assume a CRQC already exists in operational form for broad attack use, but it is also imprudent to wait for a public declaration that one has arrived. Public threat-intelligence estimates place credible CRQC emergence in the 2029–2035 range, with substantial uncertainty bands. The decisive planning question is not "when does a CRQC arrive" but "what is the confidentiality lifetime of the data you are protecting."

Crypto-agility

The ability to swap cryptographic components — algorithms, parameters, key types, vendor implementations — without redesigning systems from scratch. The enabling control for every other PQC step.

NIST CSWP 39 defines six agility dimensions: algorithm selection, key management, hardware capability, certificate lifecycle, protocol negotiation, and vendor contracts. Reducing agility to algorithm choice alone produces a migration that appears complete but fails during enforcement — the new algorithm runs, but the HSM cannot rotate keys, the CA cannot issue the new certificate type, or the procurement contract does not require the vendor to ship a future algorithm update.

Downgrade attack

An active man-in-the-middle attack that forces a cipher-suite negotiation to select classical-only algorithms, stripping the hybrid construction's post-quantum protection entirely.

If cipher-suite negotiation is not integrity-protected before it influences key establishment, an attacker can manipulate the negotiation step to drop ML-KEM from the offer. The IETF's TLS hybrid design documents identify this as a known design constraint. Mitigation: cipher-suite negotiation logging in production, integrity protection over the negotiation step before the key share is computed, and observability that surfaces classical-only negotiations as anomalous.

See also: Hybrid key exchange · TLS 1.3

Source: IETF TLS WG drafts · academic analysis

Dual certificate

A transitional PKI deployment that issues two parallel certificates — one classical, one post-quantum — for the same identity. The client validates both chains independently.

Dual-cert deployments preserve interoperability with relying parties that do not yet support PQC certificate structures, at the cost of doubled certificate-lifecycle overhead. The IETF dual-cert draft is the formal reference. Plan the dual-to-native sunset explicitly; otherwise the doubled overhead becomes permanent.

ECDH(E) Elliptic Curve Diffie–Hellman (Ephemeral)

The classical key-agreement protocol that has been the workhorse of TLS 1.3, IPsec, and SSH for the past decade. Broken by a sufficiently powerful quantum computer running Shor's algorithm.

In the post-quantum transition, ECDH (typically X25519 or P-256) is paired with ML-KEM in a hybrid construction as the standard initial deployment posture. The hybrid provides a security floor — an attacker must break both components independently — and maintains interoperability with endpoints that do not yet support ML-KEM.

See also: Hybrid key exchange · X25519 · ML-KEM

Source: RFC 8446 (TLS 1.3) · IETF

ECDSA Elliptic Curve Digital Signature Algorithm

The classical signature algorithm broken by Shor's algorithm. Replaced by ML-DSA (FIPS 204) for general-purpose use and SLH-DSA (FIPS 205) for conservative long-lived signing.

ECDSA signatures are 64–96 bytes; ML-DSA signatures are 2,420–4,595 bytes; SLH-DSA signatures are 7,856+ bytes. The size delta is the root operational cause of MTU, PKI chain, and firewall compatibility surprises in early deployment. EdDSA (Ed25519) has the same quantum-vulnerability profile as ECDSA and is in the same migration cohort.

See also: ML-DSA · SLH-DSA · Shor's algorithm

Source: FIPS 186-5 · NIST IR 8547

FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard

The NIST standard that specifies ML-KEM for key establishment. Replaces RSA and ECDH in TLS, VPN, and any session-setup handshake. Finalized August 2024.

FIPS 203 specifies three ML-KEM parameter sets — ML-KEM-512, -768, -1024 — corresponding to NIST security levels 1, 3, and 5. CNSA 2.0 mandates ML-KEM-1024 for National Security Systems. ML-KEM-1024 produces a 1,568-byte ciphertext compared to a few hundred bytes for ECDH; this size delta is the cause of MTU fragmentation issues during early deployment.

FIPS 204 Module-Lattice-Based Digital Signature Standard

The NIST standard that specifies ML-DSA for general-purpose digital signatures. Replaces RSA and ECDSA in TLS certificates, JWTs, document signing. Finalized August 2024.

FIPS 204 specifies three ML-DSA parameter sets — ML-DSA-44, -65, -87 — with public-key sizes of 1,312, 1,952, and 2,592 bytes and signature sizes of 2,420, 3,293, and 4,595 bytes. CNSA 2.0 mandates ML-DSA-87 for National Security Systems.

See also: ML-DSA · PKI chain validation

Source: NIST FIPS 204, August 2024

FIPS 205 Stateless Hash-Based Digital Signature Standard

The NIST standard that specifies SLH-DSA — a hash-based, stateless signature scheme. The preferred conservative alternative for root CA signing and long-lived trust anchors. Finalized August 2024.

SLH-DSA's security depends entirely on the security of its underlying hash function, which makes it the diversity option in cases where the lattice-based assumption of ML-DSA must be hedged. Signatures are large (7,856+ bytes at the small parameter set), which is the cost paid for conservative-design certainty.

See also: SLH-DSA · Hash-based signature

Source: NIST FIPS 205, August 2024

Grover's algorithm

A quantum algorithm that provides a quadratic speedup over classical brute-force search. The reason AES-128 is borderline and AES-256 is preferred in a post-quantum future.

Grover's algorithm reduces the effective security of a symmetric cipher with n-bit keys from 2^n to roughly 2^(n/2) operations. It does not break symmetric encryption — it weakens it. The implication is a key-size uplift, not an algorithm change, for the symmetric layer. The public-key layer requires the algorithm change.

Hash-based signature

A signature scheme whose security depends only on the security of a hash function. The conservative-design family of post-quantum signatures, of which SLH-DSA (FIPS 205) is the standardized stateless variant.

Hash-based signature schemes (stateless: SPHINCS+/SLH-DSA; stateful: LMS, XMSS) are valued because their security analysis is well-understood and depends only on collision-resistance and pre-image properties of the hash. The cost is large signature size and, for stateful variants, the operational risk of key reuse. Stateless schemes (FIPS 205) avoid the state-management problem at the cost of larger signatures.

HNDL Harvest Now, Decrypt Later

A surveillance strategy in which adversaries collect and store encrypted traffic today, waiting to decrypt it once a CRQC becomes available. The reason long-lived data is already at risk today, not at some theoretical future date. Also called SNDL — Store Now, Decrypt Later.

HNDL is documented in threat intelligence including a 2025 Federal Reserve research paper analyzing HNDL-motivated collection in the financial sector. The structural implication for privacy and compliance: the breach event (exfiltration) and the discovery event (decryption) are separated by years or decades, which most data-protection frameworks were not designed to address. See Privacy & Legal briefing for the legal-time dimension.

See also: CRQC · SNDL · Shor's algorithm

Source: Federal Reserve PQC paper 2025 · CISA · Cisco

Hybrid key exchange

A construction that combines a classical KEM (typically X25519 or P-256) with a post-quantum KEM (ML-KEM) in parallel, combining their outputs through a KDF. The standard initial deployment posture for the PQC transition.

Hybrid provides a security floor (an attacker must break both components independently) and maintains interoperability with endpoints that do not yet support ML-KEM. The IETF draft draft-ietf-tls-mlkem formalizes the hybrid group for TLS 1.3. Critical architectural discipline: hybrid is a time-bounded transitional state, not a permanent posture — define an explicit sunset condition tied to vendor support or endpoint coverage.

See also: ML-KEM · KDF · Downgrade attack

Source: IETF draft-ietf-tls-mlkem · NIST CSWP 39

IETF Internet Engineering Task Force

The standards body that formalizes protocol-level integrations of PQC algorithms — most notably the TLS 1.3 hybrid key-exchange draft and the LAMPS working-group certificate drafts.

For PQC adopters, the IETF documents that matter most are: draft-ietf-tls-mlkem (hybrid ML-KEM in TLS 1.3), the LAMPS working-group drafts on PQC certificates, and the dual-cert / composite-cert drafts. These are tracked alongside NIST FIPS standards because algorithm specifications and protocol integrations move on different cadences.

See also: Hybrid key exchange · TLS 1.3

Source: IETF working group drafts

KDF Key Derivation Function

A function that produces a final session key from one or more shared secrets. In hybrid constructions, the KDF combiner is the cryptographic glue that combines the classical and post-quantum components.

Hybrid schemes must combine the outputs of both KEMs through a cryptographically sound combiner. A naive concatenation without proper domain separation may allow the composite key to inherit the weakness of either component under adversarial conditions. Use standardized combiners from IETF drafts and reviewed library implementations — do not roll your own.

KEM Key Encapsulation Mechanism

A public-key primitive for establishing a shared secret. Replaces the role that ECDH and RSA key transport played in classical TLS and VPN. ML-KEM is the standardized post-quantum KEM (FIPS 203).

A KEM has three operations: key generation (produces a public/private pair), encapsulation (the sender uses the public key to produce a ciphertext and a shared secret), and decapsulation (the receiver uses the private key to recover the shared secret from the ciphertext). KEMs are the post-quantum replacement model for both key-exchange and key-transport in TLS, IPsec, and SSH.

Lattice-based cryptography

The mathematical hardness assumption underlying ML-KEM (FIPS 203) and ML-DSA (FIPS 204). Based on the difficulty of finding short vectors in high-dimensional lattices — a problem believed to be hard for both classical and quantum computers.

The specific hardness assumption is "Module Learning With Errors" (M-LWE). Lattice cryptography is the dominant family in the NIST PQC standards because of its combination of relatively modest key sizes, efficient implementation, and well-studied security analysis. SLH-DSA (FIPS 205) is the hash-based alternative chosen specifically to provide algorithm diversity against the lattice assumption.

ML-DSA Module-Lattice Digital Signature Algorithm

The general-purpose post-quantum signature standardized in FIPS 204. Derived from CRYSTALS-Dilithium. Used for TLS certificates, JWTs, document signing, and any general-purpose signature.

Three parameter sets: ML-DSA-44 (1,312-byte public key, 2,420-byte signature), ML-DSA-65 (1,952 / 3,293), ML-DSA-87 (2,592 / 4,595). CNSA 2.0 mandates ML-DSA-87 for NSS. The 18× size delta versus RSA-2048 signatures is the root operational cause of MTU and PKI compatibility surprises in early deployment.

See also: FIPS 204 · Lattice-based cryptography · SLH-DSA

Source: NIST FIPS 204, August 2024

ML-KEM Module-Lattice Key Encapsulation Mechanism

The post-quantum key encapsulation mechanism standardized in FIPS 203. Derived from CRYSTALS-Kyber. Replaces RSA and ECDH for key establishment in TLS, VPN, SSH, and any session-setup handshake.

Three parameter sets — ML-KEM-512, -768, -1024 — corresponding to NIST security levels 1, 3, and 5. CNSA 2.0 mandates ML-KEM-1024 for NSS. ML-KEM-1024 produces a 1,184-byte public key and a 1,568-byte ciphertext, compared to 32 bytes each for X25519.

See also: FIPS 203 · KEM · Hybrid key exchange

Source: NIST FIPS 203, August 2024

MTU Maximum Transmission Unit / fragmentation

The largest IP packet size a network path can carry without fragmentation. PQC ciphertexts and signatures frequently exceed the standard 1,500-byte Ethernet MTU, causing fragmented packets that some stateful firewalls and deep-packet inspection appliances silently drop.

TLS handshake records carrying ML-KEM-1024 ciphertexts or ML-DSA-87 signatures will routinely exceed 1,500 bytes once the certificate chain is included. Mitigation: audit MTU settings across the full path including DPI and IPS, update firewall policies that drop fragmented IP packets, and test the handshake at every MTU boundary in the path before production rollout.

See also: ML-KEM · ML-DSA · PKI chain validation

Source: IETF · operational reports

NCCoE National Cybersecurity Center of Excellence

A NIST applied-research center that publishes practical migration guidance, including NIST SP 1800-38 on PQC migration.

NIST SP 1800-38 — "Migration to Post-Quantum Cryptography" — is the practical companion to the FIPS standards. It explicitly notes that prior cryptographic replacement efforts have taken many years and that discovery must begin before any algorithm changes are scheduled.

NIST IR 8547

NIST's internal report describing the planned transition from quantum-vulnerable cryptographic algorithms. The reference for the transition-timeline conversation outside the federal NSS perimeter.

IR 8547 covers the deprecation schedule for classical algorithms (anticipated 2035 full deprecation), the rationale for the transition pace, and the operator-facing implications. It is in initial-public-draft status as of late 2024 and is the document to watch for updated guidance on the private-sector timeline.

NIST Security Level

A scale (1 through 5) NIST uses to compare PQC parameter sets against the difficulty of breaking well-known classical primitives. Level 1 corresponds to AES-128, Level 3 to AES-192, Level 5 to AES-256.

ML-KEM-512, -768, -1024 correspond to Levels 1, 3, 5. ML-DSA-44, -65, -87 also map to Levels 2/3/5 respectively. The level is a guidance heuristic — it is not a guarantee of equivalent attack difficulty under all adversary models.

NSM-10 National Security Memorandum 10

The May 2022 White House memorandum directing federal agencies to begin the migration to quantum-resistant cryptography. The policy foundation that CNSA 2.0 and OMB M-23-02 sit on top of.

NSM-10 sets the 2035 horizon for federal PQC migration, directs NIST to publish standards, and orders OMB and CISA to issue implementation guidance. It is the upstream policy reference cited in OMB M-23-02 and the CNSA 2.0 background documents.

OCSP Online Certificate Status Protocol

The protocol that lets a client check whether a certificate has been revoked. In the PQC transition, OCSP responders must be updated in lockstep with the CA infrastructure.

Certificate chains that include PQC or hybrid signatures may fail validation silently in legacy OCSP responders and relying-party validators that do not support the new certificate structures. Test full chain validation end-to-end, not just at the server endpoint; include OCSP, intermediate CAs, and at least one representative legacy client.

OMB M-23-02

The U.S. Office of Management and Budget memorandum requiring federal agencies to submit annual inventories of quantum-vulnerable systems through 2035. The compliance baseline for federal PQC migration.

M-23-02 operationalizes NSM-10 by mandating cryptographic inventory practice across federal civilian agencies. It is the document cited in federal PQC strategy and execution-plan templates. Private-sector regulated industries should expect their sector regulators to mirror its inventory and progress-reporting requirements within a one-to-three-year lag.

PFS Perfect Forward Secrecy

A property of a key-exchange protocol that ensures session keys cannot be reconstructed even if long-term private keys are later compromised. The structural defense that makes HNDL a threat against the key-exchange layer, not the long-term-key layer.

TLS 1.3 (ECDH-based) achieves PFS, which is why the HNDL threat against today's TLS sessions is captured-traffic decryption rather than long-term-key compromise. Hybrid key exchange preserves PFS in the post-quantum transition — both the classical and PQ components contribute ephemeral material to the final session key.

PKI chain validation

The end-to-end process of verifying a certificate by walking from the leaf, through any intermediate CAs, to a trusted root. PQC certificates may fail this validation silently in legacy infrastructure.

Validation must succeed at every node in the chain: leaf certificate, intermediate CA certificates, root CA, and the OCSP / CRL infrastructure. Legacy validators that do not yet support PQC certificate structures may produce silent failures or fall back to classical-only paths in dual-cert deployments. Test the full chain end-to-end before production rollout.

See also: CA · OCSP · Composite certificate

Source: IETF PKIX · operational reports

QCCPA Quantum Computing Cybersecurity Preparedness Act

The 2022 U.S. federal law directing OMB to issue migration guidance for PQC following NIST's standards finalization. Sits alongside NSM-10 and OMB M-23-02 in the federal compliance baseline.

QCCPA is the statutory authority for OMB's PQC inventory and migration mandates. Together with M-23-02, it establishes the framework within which federal agencies are accountable for PQC migration progress. Private-sector compliance programs use it as a citation when documenting that PQC is a recognized federal policy priority.

RSA Rivest–Shamir–Adleman

The classical public-key algorithm that has underpinned much of the public-key cryptography in deployed systems since the late 1970s. Broken by Shor's algorithm and being replaced by ML-KEM (key establishment) and ML-DSA / SLH-DSA (signatures).

RSA-2048 produces 256-byte ciphertexts and 256-byte signatures. ML-KEM-1024 produces 1,568-byte ciphertexts; ML-DSA-87 produces 4,595-byte signatures. The migration target is generally ML-KEM and ML-DSA for general use, with SLH-DSA reserved for long-lived signing where conservative-design diversity is valued.

See also: ML-KEM · ML-DSA · Shor's algorithm

Source: PKCS #1 · RFC 8017

Shor's algorithm

A quantum algorithm that factors large integers and computes discrete logarithms efficiently — the algorithm whose existence breaks RSA, ECDH, and ECDSA once a sufficiently powerful quantum computer (a CRQC) is built.

Shor's algorithm is the reason the public-key layer of classical cryptography must be replaced. Symmetric encryption (AES) and hash functions (SHA-2, SHA-3) are not broken by Shor's algorithm — they are only weakened by Grover's. The decisive question for PQC planning is therefore the public-key layer.

See also: CRQC · Grover's algorithm · RSA

Source: Shor (1994) · NIST IR 8547

SLH-DSA Stateless Hash-Based Digital Signature Algorithm

The hash-based, stateless signature scheme standardized in FIPS 205. Derived from SPHINCS+. The conservative-design alternative used where algorithm diversity matters — root CAs, firmware, code signing, long-lived trust anchors.

SLH-DSA's security depends entirely on the security of its hash function, which makes it the diversity option against the lattice assumption underlying ML-DSA. Signature sizes range from 7,856 bytes (SLH-DSA-128s) to over 49 KB at the larger parameter sets — the cost paid for conservative-design certainty. Use where the verification surface is narrow and the signing event is infrequent.

See also: FIPS 205 · Hash-based signature

Source: NIST FIPS 205, August 2024

SNDL Store Now, Decrypt Later

A synonym for HNDL — Harvest Now, Decrypt Later. Used interchangeably in academic and policy literature.

See HNDL for the full entry.

TLS 1.3 Transport Layer Security 1.3

The most widely deployed secure transport protocol. The IETF draft for ML-KEM in TLS 1.3 formalizes the hybrid key-exchange construct that is the standard PQC deployment posture for the protocol.

TLS 1.3 (RFC 8446) is the version on which PQC integration is being standardized. The relevant IETF draft is draft-ietf-tls-mlkem. Earlier TLS versions are not receiving PQC integration; the migration is implicitly also a migration to TLS 1.3 for any endpoint that has not already moved.

See also: Hybrid key exchange · Downgrade attack · ML-KEM

Source: IETF RFC 8446 · draft-ietf-tls-mlkem

X25519

The widely deployed elliptic-curve Diffie–Hellman variant. The standard classical partner in a hybrid ML-KEM construction.

X25519 (defined in RFC 7748) produces 32-byte public keys and 32-byte shared secrets, with strong implementation-side properties and broad library support. In hybrid TLS 1.3 deployments, X25519 + ML-KEM-768 is the prevalent combination; X25519 + ML-KEM-1024 is used where CNSA 2.0 levels are targeted.

See also: ECDH(E) · Hybrid key exchange

Source: RFC 7748 · IETF