The terms on this page
- FIPSFederal Information Processing Standard
- the US government's standards series, and where the post-quantum algorithms were published
- ACVPAutomated Cryptographic Validation Protocol
- the test harness an implementation runs against to claim conformance
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry, ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry, SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry, NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry are defined in the glossary.
Read this first
ACVP proves an algorithm computes the right outputs on well-formed inputs. Conformance asks whether the implementation follows the whole standard, including the input checks and reject paths honest test vectors never exercise. FIPS 140-3 validates a cryptographic module (its boundary, key management, self-tests, and roles) with algorithm validation as a prerequisite, not the whole job. They overlap but they are not interchangeable, and a certificate on one axis says nothing about the others.
Ask a vendor whether their post-quantum crypto is "validated" and you may get any of three answers: it passes NIST's ACVP test vectors, it conforms to the standard, or the module carries a FIPS 140-3 certificate. These sound like grades of the same thing. They are not: each answers a different question, and a strong claim on one axis routinely gets read as coverage on all three. Pulling them apart is the difference between knowing what you have bought and assuming it.
ACVP and CAVP: algorithmic correctness
The Automated Cryptographic Validation Protocol (ACVP) is NIST's protocol for delivering known-answer test vectors and collecting an implementation's responses. It is the testing mechanism behind the Cryptographic Algorithm Validation Program (CAVP), which issues the algorithm certificates. The check is precise and narrow: feed fixed, well-formed inputs, compare the outputs byte-for-byte against the expected answers, and confirm the algorithm computes correctly for each approved parameter set.
What an ACVP/CAVP certificate proves, and what it does not, is worth stating plainly:
- Proves: the algorithm produces the standard's outputs on honest, well-formed inputs, across the parameter sets it was tested for. That catches transcription errors, endianness bugs, and wrong parameters.
- Does not prove: how the implementation handles malformed input, whether the reject paths behave as the standard requires, whether it is free of timing or other side-channel leakage, or anything about the module that wraps the algorithm.
Conformance: the whole standard, including the reject paths
Conformance is a broader axis than ACVP. It asks whether the implementation follows the full standard: not just the arithmetic on honest inputs, but the input validation and reject-path behaviour the algorithm vectors never touch. FIPS 203 makes the gap concrete: its §7.2 encapsulation-key modulus check and §7.3 ciphertext-length check are normative, and implicit rejection must return a deterministic pseudo-random secret indistinguishable, by timing, from an accept. No honest known-answer vector contains an out-of-range key or a wrong-length ciphertext, so an implementation can pass every ACVP vector while silently skipping the very checks that make it conformant. This is the behaviour our conformance testing exercises, and it is what the FIPS 203 checklist walks through line by line.
The same shape holds for ML-DSA and SLH-DSA: verification must reject malformed keys and signatures and apply domain separation correctly, all on paths the vectors cannot reach. Conformance is orthogonal to ACVP, being spec-adherence including the refusals, not a stricter version of the same test.
FIPS 140-3: the module, not just the algorithm
FIPS 140-3 validates a cryptographic module under NIST and CCCS's Cryptographic Module Validation Program (CMVP). Its scope is the module as a whole: the cryptographic boundary, the set of approved algorithms, key management, power-up and conditional self-tests, roles and authentication, and at higher levels physical security. Algorithm validation via CAVP/ACVP is a prerequisite for a 140-3 validation: you cannot validate the module without validated algorithms inside it. But 140-3 is about the module, not the algorithm, so a 140-3 certificate answers questions ACVP never asks, and still does not, by itself, certify reject-path conformance.
How the three relate
The cleanest way to hold them is as nested-and-orthogonal, not as a ladder:
- ACVP ⊆ FIPS 140-3. Algorithmic correctness is a prerequisite the module validation subsumes: every 140-3 module has CAVP-validated algorithms inside it.
- Conformance is a distinct axis. Spec-adherence including input validation and reject paths is orthogonal: neither ACVP nor, by itself, a 140-3 certificate guarantees it.
- Audit is yet another axis. Whether the code is exploitable in your context (side channels, RNG quality, memory handling) is a separate question again, the one an audit answers.
"FIPS 140-3 validated" and "passes ACVP" are not blanket assurances
Buyers treat either phrase as a stamp that the crypto is simply correct and safe. They answer different, narrow questions. The algorithm computes right on honest inputs; the module meets CMVP's requirements. Neither one proves the reject-path conformance or the absence of exploitable bugs. Before you rely on a claim, ask which axis it actually covers: correctness, conformance, module validation, or security. A certificate on one is not evidence on the others.
Reading a vendor's certificates for what they cover
We help you read the claims for what they cover and close the gaps between them. We conformance-test the FIPS 203 (ML-KEM) and ML-DSA implementation you actually ship against the input checks and reject paths the vectors miss (certification), and we assess whether it is exploitable in your deployment (audit), the two axes a CAVP or 140-3 certificate leaves open. The deliverable is a signed statement of which axis has been verified and how, so "validated" stops being a word that means four different things at once.