Reading the Labels: What ML-KEM-768, ML-DSA-65 and SLH-DSA-SHA2-128s Tell You

A tyre's sidewall carries a code such as 205/55 R16 91V. To most drivers it is noise; to anyone who knows how to read it, it gives width, height, construction, wheel size, load and speed rating in one line. Post-quantum cryptography now has its own sidewall codes: ML-DSA-65, SLH-DSA-SHA2-128s, ML-KEM-768, X25519MLKEM768, mlkem768x25519-sha256, 2.16.840.1.101.3.4.3.18. They appear on vendor datasheets, in configuration screens, in certificates and in procurement questionnaires, usually next to the reassuring word quantum-safe. This guide teaches anyone to read those labels: what each part of a name means, which numbers indicate strength and which do not, how the same idea is spelled differently in different places, how to tell a draft from a final standard, and which claims on a datasheet carry real evidence. It finishes with a worked example and the questions that turn a vague promise into a checkable fact.

Four questions every label answers

Every post-quantum label, however it is spelled, is trying to answer four questions. Reading a label well means finding each answer, or noticing that it is missing. The first question is which job the algorithm does. There are two jobs. Key establishment lets two machines agree a shared secret over a network, and the standard for it is ML-KEM (short for Module-Lattice-Based Key-Encapsulation Mechanism), published as Federal Information Processing Standard (FIPS) 203. Signing proves who produced something and that it was not altered, and the standards for it are ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205). A product that says it is quantum-safe without saying which job is protected has told you almost nothing.

The second question is how strong. Each standard comes in several sizes, and the label says which. The third question is whether the method is hybrid, meaning combined with a familiar classical algorithm so that both must be broken, or pure, meaning post-quantum on its own; and if hybrid, with which classical partner. The fourth question is which version of the standard. The algorithms went through years of public drafts under earlier names, and early implementations of a draft do not interoperate with the final standard.

Keep those four questions in mind and the rest of this guide is simply learning where each answer hides in each kind of label.

Why bother, if the experts on each side will sort it out? Because the people who first meet these labels are rarely cryptographers. They are buyers filling in procurement questionnaires, architects comparing products, auditors reading evidence, and engineers pasting settings from documentation. Vendors are under pressure to claim post-quantum readiness, and the word quantum-safe costs nothing to print. The four questions cost nothing to ask either, and they are usually enough to separate a specification from a slogan.

1. Which job: key establishment (ML-KEM) or signing (ML-DSA, SLH-DSA)?
2. How strong: which size, and which security category?
3. Hybrid or pure: and if hybrid, combined with which classical algorithm?
4. Which version: the final FIPS standard, or a pre-standard draft?

The numbers are shapes, not bits

The most common misreading is to treat the number in a name as a key length, the way RSA-2048 means a 2,048-bit key. In the post-quantum names it is not. For the three ML-KEM sizes, 512, 768 and 1024, the number is 256 multiplied by a small whole number, 2, 3 or 4, which sets how many blocks of 256 numbers the underlying structure uses. For ML-DSA's 44, 65 and 87, the two digits are the shape of a grid of numbers inside the algorithm: four by four, six by five, and eight by seven. They are useful to engineers and meaningless as a strength score.

Strength is expressed separately, as a security category from 1 to 5 defined by the National Institute of Standards and Technology (NIST). NIST pins each category to a benchmark attack that cryptographers already understand well. Category 1 means breaking the algorithm should take at least as much work as recovering a 128-bit key for the Advanced Encryption Standard (AES) by exhaustive search; category 3 compares with a 192-bit AES key and category 5 with a 256-bit one. Categories 2 and 4 compare with finding a collision, two inputs with the same output, in the SHA-256 and SHA-384 hash functions.

That gives a quick translation. Read across, the three ML-KEM sizes land in categories 1, 3 and 5. ML-DSA's 65 and 87 sit in categories 3 and 5, but ML-DSA-44 is category 2, not 1, a detail that matters when a policy asks for a minimum category. SLH-DSA names carry 128, 192 or 256, which do map to categories 1, 3 and 5. The United States National Security Agency's suite for national security systems, the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), simply takes the top category: ML-KEM-1024 and ML-DSA-87. Firefox even has a separate administrator policy that offers ML-KEM-1024 for environments that must follow it.

Higher is not automatically better. A higher category means larger keys, ciphertexts and signatures, and the costs land on every connection and every signed object. ML-KEM-768 at category 3 is the size most software chose for its default hybrid, and many organisations treat category 3 as a sensible floor for general use, reserving category 5 for systems with policies that demand it. The right reading of a category is 'is this at least what our policy requires?', not 'is this the biggest available?'

It is also worth knowing what a category does not tell you. It describes the mathematics of the parameter set, assuming a correct implementation. It says nothing about whether a particular product leaks secrets through timing, handles errors safely, generates good randomness or protects its private keys. Those are properties of the implementation and its operation, which is why the evidence questions later in this guide matter as much as the name.

Reading an SLH-DSA name, part by part

SLH-DSA names are the longest because they carry three separate choices. Take SLH-DSA-SHA2-128s. After the algorithm's name comes the hash family, the type of one-way scrambling function the scheme is built from: SHA2 or SHAKE, both standard NIST families. Neither is weaker; the choice usually follows what a chip or library already accelerates. Then comes 128, 192 or 256, the strength, which as above maps to categories 1, 3 and 5. Last comes a single letter: s for sets designed for relatively small signatures, f for sets designed for relatively fast signing. SLH-DSA-SHA2-128s has a 7,856-byte signature; SLH-DSA-SHA2-128f has a 17,088-byte one with quicker signing.

So a datasheet that says only 'SLH-DSA' leaves three choices open, and they matter: the difference between the smallest and largest standard SLH-DSA signature is more than a factor of six. A complete label names all three.

One more distinction applies to both signature standards. The plain versions, often called pure ML-DSA or pure SLH-DSA, sign the message itself. Pre-hash versions, labelled HashML-DSA and HashSLH-DSA, first compress the message with a named hash function and sign the result, which can help when a large file is signed by a separate device. NIST registers separate identifiers for the pure and pre-hash forms, and a signature made one way will not verify the other way. A label that says ML-DSA without saying which form leaves a real interoperability question open.

The same parameter set also appears under slightly different spellings depending on where you meet it. The standard writes SLH-DSA-SHA2-128s; the certificate identifier is called id-slh-dsa-sha2-128s; software libraries often use their own variations with underscores or different capitalisation. They all mean the same thing, and the three choices, hash family, strength and letter, survive every spelling. Learning to find those three parts is more useful than memorising any one format.

Same idea, many spellings

Each protocol and each system names things in its own style, so the same algorithm appears under several spellings. In Transport Layer Security (TLS), which secures the padlocked web, key-exchange methods are called groups and identified by a registered number, a codepoint, held by the Internet Assigned Numbers Authority (IANA). The hybrid most software uses is X25519MLKEM768, codepoint 0x11EC, defined in RFC 10024. Its siblings are SecP256r1MLKEM768 and SecP384r1MLKEM1024, which pair ML-KEM with two standard elliptic curves. Pure post-quantum groups also exist, MLKEM512, MLKEM768 and MLKEM1024, but the registry does not mark them as recommended for general use.

RFC 10024 even contains a small confession: the name X25519MLKEM768 lists X25519 first, but on the wire the ML-KEM part comes first, for historical reasons. It is a harmless quirk, and a useful reminder that names are labels agreed by people, not descriptions generated by the mathematics. Windows writes the same group as x25519_mlkem768 in its settings. Secure Shell (SSH) has its own names: mlkem768x25519-sha256 is the ML-KEM hybrid that OpenSSH uses by default, while sntrup761x25519-sha512 is a different post-quantum algorithm, Streamlined NTRU Prime, which OpenSSH adopted earlier and which is not a NIST standard.

Certificates use a third style: object identifiers (OIDs), dotted strings of numbers registered in a global tree. NIST's register lists id-ml-dsa-65 as 2.16.840.1.101.3.4.3.18, id-slh-dsa-sha2-128s as 2.16.840.1.101.3.4.3.20 and id-alg-ml-kem-768 as 2.16.840.1.101.3.4.4.2. Hybrid signatures for certificates, called composites, have names that list both partners, such as id-MLDSA65-ECDSA-P256-SHA512, which combines ML-DSA-65 with an elliptic-curve signature; as of April 2026 those composite names were still in an Internet-Draft, not a finished standard.

Knowing the spellings tells you where to look for evidence. A certificate viewer shows the signature algorithm, often as an OID or a name derived from it, so an ML-DSA certificate can be recognised directly. TLS diagnostic tools report the negotiated group by name, and SSH clients in verbose mode print the key-exchange algorithm they agreed. Each of those is a place where a label stops being a claim on a datasheet and becomes an observed fact about a real connection or a real certificate.

Draft or final?

Before NIST finished its standards in August 2024, the algorithms were public candidates with different names: Kyber became ML-KEM, Dilithium became ML-DSA and SPHINCS+ became SLH-DSA. Early adopters deployed the drafts, which was a sensible way to learn, but the final standards changed details, and the drafts do not interoperate with the finals. Google explained this when it moved Chrome from Kyber to ML-KEM in version 131: the final version is incompatible with the deployed draft, so the TLS codepoint changed from 0x6399 to 0x11EC, and Chrome would not offer both at once.

The IANA registry now marks the old Kyber hybrid, X25519Kyber768Draft00, as obsolete. That gives a very practical reading rule. A datasheet, configuration file or scanner report that says Kyber, Dilithium or SPHINCS+ is probably describing pre-standard code. It may be harmless documentation lag, or it may mean the product speaks a version that current browsers and libraries no longer accept. Either way it deserves one question: does this product support the final standard, and under which codepoint or identifier?

The reverse also happens. A product may implement the final ML-KEM but describe it as Kyber because the marketing copy is older than the code. Names on a datasheet are claims; codepoints and identifiers in a configuration or a captured connection are evidence.

Dates help too. A document that predates August 2024 cannot be describing a product built against the final standards, because they did not exist yet. A product that claims post-quantum support from earlier than that was, at best, running a draft. That is not a criticism, since early experiments were how the industry learned, but it is a reason to ask what changed since, and whether the product was updated to the final version.

The claims ladder

The last part of a label is the claim made about it, and claims come in very different strengths. At the bottom is 'supports post-quantum cryptography' or 'quantum-ready', which may mean anything from a working feature to a roadmap. One step up is 'implements FIPS 203' or a named algorithm: a statement about the code, made by the vendor. Next is an algorithm validation certificate from NIST's Cryptographic Algorithm Validation Program (CAVP), which tests a specific implementation of a specific algorithm against known answers. At the top is a FIPS 140-3 module validation, which covers a whole cryptographic module, its approved functions and how it operates. NIST notes that algorithm validation is a prerequisite for module validation.

Two practical consequences follow. First, 'FIPS 140-3 validated' on a datasheet does not by itself mean the post-quantum algorithms are inside the validated boundary; a module validated years ago may cover only classical algorithms. The useful question is which certificate, and whether it lists ML-KEM, ML-DSA or SLH-DSA. Second, even a validated algorithm can be switched off. The datasheet should say whether the post-quantum option is enabled by default or must be configured, because defaults decide what most installations actually do.

A third consequence is about scope. Validation applies to a specific module, often a cryptographic library or a hardware device, at a specific version. An application that uses a validated library inherits that evidence only for the functions it actually calls, in the mode the certificate describes. When a vendor says its product is validated, the precise question is which module inside the product holds the certificate, at which version, and whether the product uses it for the post-quantum operations being claimed.

Put together, a complete answer from a vendor names the job, the parameter set and category, hybrid or pure with the partner, the codepoint or identifier, the default state, and the validation evidence. Anything less is a promise rather than a specification.

1. Which job is protected: key establishment, signing, or both?
2. Which parameter set and security category?
3. Hybrid or pure, and with which classical partner?
4. Which codepoint, algorithm name or OID appears in the configuration?
5. Is it on by default, or does someone have to enable it?
6. Which validation certificate covers it, if any?

Reading a datasheet with three habits

Here is an invented but realistic datasheet line, the kind found in product brochures: 'Gateway 9.2: quantum-safe TLS with Kyber768 hybrid, ML-DSA certificates, SLH-DSA firmware signing, FIPS 140-3 validated.' Read with the four label questions, it raises six concrete questions. Kyber768 is a draft name, so does the gateway speak X25519MLKEM768 under codepoint 0x11EC, and is it on by default? ML-DSA certificates of which size, pure or composite, with which identifier? SLH-DSA with which hash family, strength and letter? And does the FIPS 140-3 certificate actually list the post-quantum algorithms?

Three further habits complete the reading. The first is to ask what each connection actually negotiates, not what the product supports: a gateway can support the hybrid while the services behind it still use classical key exchange, and only a captured connection or a log of the negotiated group tells the truth. The second is to count where signature bytes go: ML-DSA certificates add kilobytes to every new connection, and if the same product issues signed tokens, those bytes may travel with every request and meet header limits along the way. The third is to ask who verifies each signature and whether that verifier can ever be updated: the gateway's firmware signature is checked by boot code that may never change, which is exactly where a conservative choice such as SLH-DSA earns its size, while its certificates are checked by software that updates regularly.

With those habits, a sentence of marketing becomes a short list of facts to confirm, and the confirmed facts can go straight into a cryptographic inventory.

That inventory is where label reading pays off over time. A record that says 'gateway, TLS, X25519MLKEM768, on by default since a given date, validated by a named certificate' can be checked again next year, compared across products and handed to an auditor. A record that says 'gateway, quantum-safe' cannot. The extra words cost a few minutes when the product is chosen and save weeks when someone later needs to know what is really protected.

Datasheet: "quantum-safe TLS (Kyber768 hybrid), ML-DSA certificates,
            SLH-DSA firmware signing, FIPS 140-3 validated"

Kyber768 hybrid      -> draft name: X25519MLKEM768 (0x11EC) supported? on by default?
ML-DSA certificates  -> 44, 65 or 87? pure or composite? which OID?
SLH-DSA firmware     -> SHA2 or SHAKE? 128, 192 or 256? s or f?
FIPS 140-3 validated -> which certificate? does it list ML-KEM / ML-DSA / SLH-DSA?

What this means for AI agents and the people who run them

AI agents and coding assistants now read datasheets, answer security questionnaires and write configuration files, often faster than any person can check them. That makes label literacy something to build into how agents are instructed and reviewed. An assistant asked whether a product is quantum-safe should be expected to extract the four answers, job, strength, mix and version, and to say plainly when one is missing, rather than repeating the word quantum-safe back. An assistant that writes a TLS configuration naming Kyber768, or a draft codepoint, is producing something current browsers will not speak, and a reviewer who knows the labels will catch it in seconds.

Agents also make good label checkers once they are told what to look for. A simple automated review can flag configuration files and dependency manifests that mention draft names, pure post-quantum groups where a hybrid was intended, ML-DSA-44 where policy requires category 3 or higher, or 'FIPS validated' claims with no certificate number. Those checks are mechanical, which is exactly the kind of work agents do reliably when the rules are written down.

There is a caution in the other direction too. Language models learned from text written over many years, much of it from the draft period, so an assistant may confidently use Kyber where ML-KEM is meant, quote parameter sizes from early drafts, or invent an identifier that looks plausible. Treat any post-quantum name, codepoint or OID produced by an assistant as a claim to verify against the standard or the official register, exactly as you would treat the same claim on a vendor's datasheet.

The deeper point is that the labels are where the three practical questions of the post-quantum move meet. What does each connection negotiate? How many signature bytes travel, and how often? Who verifies each signature, and can they ever be updated? A label read carefully answers part of each question, and a missing part of a label is usually the exact thing that needs asking next.

None of this requires becoming a cryptographer. It requires the same patience a careful shopper applies to a tyre code or a nutrition label: knowing which parts carry meaning, refusing to let one reassuring word stand in for the details, and writing down the answers. Applied consistently, by people and by the agents that increasingly work alongside them, that patience turns a confusing transition into a list of facts that can be checked.

Glossary

Parameter set

A named bundle of settings, such as ML-KEM-768, that fixes an algorithm's size, speed and strength.

Security category

NIST's strength level from 1 to 5, defined by comparison with breaking AES keys or finding SHA hash collisions.

Hybrid

A combination of a post-quantum algorithm with a classical one, so that both must be broken.

Codepoint

A registered number that tells both sides of a protocol which method is meant, such as 0x11EC for X25519MLKEM768.

Object identifier (OID)

A dotted string of numbers, registered in a global tree, that names an algorithm inside certificates and other data formats.

Composite signature

A single signature object that combines a post-quantum and a classical signature for the same message.

Pre-hash

Signing a hash of a message rather than the message itself; HashML-DSA and HashSLH-DSA are the pre-hash forms.

CAVP

NIST's Cryptographic Algorithm Validation Program, which tests specific implementations of specific algorithms.

FIPS 140-3

The US standard for validating a whole cryptographic module, which requires validated algorithms inside it.

Further reading

1. Computer Security Objects Register: algorithm registrations (NIST)
2. TLS parameters registry (IANA)
3. RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
4. FIPS 204: Module-Lattice-Based Digital Signature Standard (NIST)
5. Cryptographic Algorithm Validation Program (NIST)
6. A new path for Kyber on the web (Google Online Security Blog, 2024)