Post-Quantum Cryptography: Three Standards, Three Different Jobs

Making a file unreadable and establishing that it came from the expected signer are different security questions. One concerns confidentiality; the other concerns identity and integrity. Reports about post-quantum cryptography can blur that distinction, presenting three standards as though they simply encrypt the same file three different ways. NIST's FIPS 203, 204 and 205, published on August 13, 2024, do not have identical roles. One defines a way to establish a shared secret key. The other two define digital signature mechanisms. [1–4]

Recognizing the distinction connects the subject with systems operating today rather than only with future quantum computers. Sometimes the component needing change establishes the key used by another encryption layer. Elsewhere, the important mechanism verifies a software signature. An algorithm's name provides insufficient information unless its job is also clear.

What the 2024 announcement establishes

NIST's official announcement released its first three finalized post-quantum standards and encouraged integration to begin. It identified ML-KEM as derived from CRYSTALS-Kyber, ML-DSA from CRYSTALS-Dilithium and SLH-DSA from SPHINCS+. The distinction between earlier family names and final standardized versions matters. An implementation bearing an earlier name cannot simply be assumed identical to the finalized specification. [1]

This article uses a news cutoff of October 13, 2026. Future plans in the 2024 announcement are not reported as subsequently accomplished events. Its focus is the verified publication and functions of these three standards, not a claim that every projected algorithm has since received approval. That prevents a planning sentence in an older announcement from becoming an invented new release.

ML-KEM establishes a key, not the entire file

FIPS 203 specifies a key-encapsulation mechanism. It allows two parties, under appropriate conditions, to establish a shared secret key across a public channel. That key can subsequently support encryption and other security tasks using symmetric cryptographic algorithms. Describing ML-KEM as a general file encryptor directly processing all document content therefore misses its role. [2]

The standard's explanation starts with one party generating an encapsulation key and a decapsulation key, retaining the latter privately. The other party uses the public encapsulation key to produce a copy of a shared secret and associated ciphertext. That ciphertext is sent back. The holder of the private decapsulation key uses it to obtain the other copy of the shared secret. The public-channel object and the secret key are distinct. [2, explanation section]

As a conceptual example, imagine two organizations establishing a connection for a large transfer. Establishing the key and transferring the file participate in one service, but remain different algorithmic tasks. This is not an implementation recipe for a particular protocol. It illustrates why the step producing shared keying material should not be confused with protection of the complete payload.

The numbers are not file sizes

ML-KEM defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. NIST presents them in increasing security strength and decreasing performance. Their numeric labels are not a statement about file length or a complete system's universal security score. They distinguish defined algorithm configurations. [2]

Selecting among them is not completed by noticing the largest number. Resources, required security strength and the surrounding systems have to be considered. The engineering implication is a choice requiring measurement. This article selects no single configuration for an unspecified organization and supplies no unsupported claim of equal speed or memory consumption across implementations.

ML-DSA asks the signature question

FIPS 204 specifies generating and verifying digital signatures with ML-DSA. Signatures help detect unauthorized changes and authenticate the signatory. This differs from confidentiality: readable signed material does not imply that the signature has failed. A signature does not have to conceal its content. [3]

For example, verification of a software package can check its relationship with an expected signing key. A valid signature does not establish that every operation in the package is error-free or appropriate for every environment. The relationship verified cryptographically and the behavior of the software remain separate subjects of examination. A specific security function should not be expanded into a substitute for all security assessment.

SLH-DSA provides a different foundation

FIPS 205 defines SLH-DSA, a stateless hash-based signature algorithm. It too concerns signing and verification rather than key encapsulation. NIST's announcement explains that its mathematical approach differs from ML-DSA's and provides an alternative foundation. Maintaining different foundations for a similar task is part of the significance of the two signature standards. [1, 4]

“Stateless” does not mean that an entire deployment needs no records or key management. It describes the algorithm's classification. An organization still has responsibilities for protecting signing keys and managing versions and verification policy. Extending a technical term beyond its scope makes the standard appear to do more than it does.

A finished standard is not a finished system

FIPS 203 explicitly limits what conformity establishes. A conforming implementation is not automatically secure, and a product containing one does not guarantee security of the overall system. Values including randomness, the private decapsulation key and the shared secret must remain protected. [2, qualifications section]

This does not make the algorithm unnecessary. It separates the mathematical mechanism from implementation conditions. Exposing a value that must remain secret creates a problem that choosing the correct algorithm name cannot repair. Adopting a standard is not the final line of security work. It provides a more clearly defined component with which that work continues.

Making the transition measurable

NIST published the final SP 800-227 in September 2025. It covers KEM definitions, properties, applications and recommendations for secure use. The publication makes visible the difference between specifying a mechanism and using it within a larger system. [5]

A practical assessment can begin by identifying cryptographic jobs separately: which component establishes a key, which verifies signatures and which encrypts data? Proposed changes can then be tested for latency, data-size effects and compatibility in the real environment. These are engineering inferences made here, not a claimed exhaustive reproduction of every recommendation in SP 800-227.

Reading documents with their dates

The inspected FIPS 203 page includes a November 17, 2025 planning note about a correction. FIPS 204 includes a July 31, 2026 note about minor issues intended for correction. These notes belong alongside the published standards. Because this article does not analyze the detailed errata spreadsheets, it does not claim a specific deployment is affected or that an algorithm has been broken. [2–3]

Treating a publication page only as its original release date overlooks later clarification. Conversely, a correction notice alone does not prove that an entire approach has failed. Following version, note and scope together narrows the sweeping conclusions often attached to security news.

Evidence-based closing: The limits of resistance claims

NIST describes ML-KEM and ML-DSA as believed secure against adversaries with quantum computing capabilities. This is not an unconditional guarantee lasting forever. FIPS 203 explicitly allows reassessment as analysis and technology advance. The appropriate conclusion is not that cryptographic security has been permanently solved, but that evaluated mechanisms have been standardized for defined tasks. [2–3]

Publication dates and algorithm roles have been checked against primary NIST sources. This article supplies no product benchmark, universal protocol interoperability test or prediction of when a cryptographically relevant quantum attack will occur. The three standards matter because they distinguish key establishment from signing rather than repeating one security job. Actual protection still depends on using those tools in a suitable context with protected keys.

Sources

1. NIST, August 13, 2024: Announcement of the first three finalized post-quantum standards.
2. NIST, FIPS 203 publication page and FIPS 203 full text, abstract, explanation and qualifications.
3. NIST, FIPS 204: ML-DSA, abstract and dated planning notes.
4. NIST, FIPS 205: SLH-DSA, abstract.
5. NIST, SP 800-227 final publication page, September 2025, abstract and document history.

Accessed October 14, 2026; news and development cutoff October 13, 2026. No development dated beyond the cutoff has been used. This is original explanatory prose.