Are Kyber-768 and ML-KEM-768 interoperable on the wire?

No. Although ML-KEM-768 (finalized in NIST FIPS 203 in August 2024) derives from CRYSTALS-Kyber-768, NIST modified encapsulation-key hashing (`H(ek)` folded into shared-secret derivation), removed initial message pre-hashing, and tightened modulus validation (`ek` byte decoding check). A Round 3 `kyber768` peer cannot complete key establishment with a conformant FIPS 203 `ML-KEM-768` peer.

Are Dilithium-3 and ML-DSA-65 signatures compatible?

No. Finalized NIST FIPS 204 (`ML-DSA-65`) added mandatory domain-separation framing (`0x00 || len(ctx) || ctx` for pure ML-DSA and `0x01` for HashML-DSA), adjusted randomness/seed expansion, and shifted parameter naming (`Dilithium3` -> `ML-DSA-65`). Signatures produced by Round 3 `dilithium3` libraries fail verification under FIPS 204 `ML-DSA-65`.

Why do AI coding assistants generate Round 3 `kyber768` imports when asked for post-quantum crypto?

Large portions of open-source training corpora from 2021–2024 imported experimental Round 3 packages (`cloudflare/circl/kem/kyber/kyber768`, `pqcrypto-kyber`, early `liboqs` bindings). Without a deterministic local referee (`ciphermap mcp`) or `PQC-PRE-001..005` CI rules, coding agents routinely emit deprecated Round 3 identifiers that compile cleanly yet fail FIPS 203/204 conformance.

Back to blog

Cryptography Engineering

Round-3 Kyber-768 & Dilithium-3 vs. Finalized NIST FIPS 203 (ML-KEM) & FIPS 204 (ML-DSA): Catching LLM & Library Drift

November 2, 2026

6 min read

In our 832-repository empirical study, one of the highest-impact surprises was how frequently repositories that believed they had “already migrated to post-quantum cryptography” were actually running pre-standardization NIST Round 3 drafts—either from early-adopter libraries added in 2022–2024 or from AI coding assistants reproducing stale training examples.

What Changed Between NIST Round 3 and Finalized FIPS 203 / 204 / 205

Round 3 Draft Identifier	Finalized NIST Standard	Breaking Wire & Specification Differences	CipherMap Rule
`Kyber512` / `Kyber768` / `Kyber1024`	FIPS 203: `ML-KEM-512` / `ML-KEM-768` / `ML-KEM-1024`	Removed initial message `H(m)` pre-hash; bound `H(ek)` into `(K, r) = G(m \|\| H(ek))`; removed `KDF` finalization in favor of direct 32-byte `K`; added mandatory encapsulation-key modulus check.	PQC-PRE-001 / 002
`Dilithium2` / `Dilithium3` / `Dilithium5`	FIPS 204: `ML-DSA-44` / `ML-DSA-65` / `ML-DSA-87`	Added domain-separation header (`0x00 \|\| len(ctx) \|\| ctx`) for pure `ML-DSA` and `0x01` for `HashML-DSA`; updated hedged signing randomness and hint/commitment encoding details.	PQC-PRE-003 / 004
`SPHINCS+` (Round 3 parameter sets)	FIPS 205: `SLH-DSA` (`SHA2` / `SHAKE` 128/192/256s/f)	Added pure vs. pre-hash domain separation (`ctx` context string up to 255 bytes), standardized 12 parameter set OIDs, and dropped Round 3 `haraka` instantiations.	PQC-PRE-005

Auditing Repositories & Blocking AI Regressions Locally

Standard regex searches for rsa or ecdsa completely miss Round 3 PQC drift—leaving teams with non-conformant cryptography hidden inside Go modules (e.g., circl/kem/kyber/kyber768 instead of Go 1.24+ standard library crypto/mlkem or circl/kem/mlkem/mlkem768), Rust crates, Python wheels, or JNI `.so` libraries.

# 1. Discover classical RSA/ECC debt AND pre-FIPS Round 3 drift locally (Free)
ciphermap scan . --offline --no-telemetry --exclude-vendored

# 2. Check upstream payload/allocation bounds before 15x-50x PQC key/sig expansion (Free)
ciphermap preflight . --offline --no-telemetry

# 3. Block AI coding agents from introducing kyber768/dilithium3 in Cursor or Claude Code (Tier B)
ciphermap mcp --workspace .