Search every question across sub-FAQs

FIPS 203 covers ML-KEM, a module-lattice-based key-encapsulation mechanism used to establish a shared secret key over a public channel. It is the post-quantum key-establishment standard in this set, not a digital signature standard.

FIPS 204 covers ML-DSA, a module-lattice-based digital signature algorithm for generating and verifying signatures. FIPS 205 covers SLH-DSA, a stateless hash-based digital signature algorithm based on SPHINCS+. Both signature standards apply to public-key-based signature systems operated by federal agencies or operated for them under contract, and their use is also available to private and commercial organizations.

The evidence should show the algorithm, parameter set, module boundary, and interface actually used. A bare statement that a product is post-quantum or FIPS-ready is not enough because the NIST standards include parameter-set choices, input checks, approved random bit generation, private-key or decapsulation-key safeguards, and restrictions on exposing testing-only internal interfaces.

For ML-KEM, record the chosen parameter set and whether encapsulation keys, decapsulation keys, and ciphertexts are checked before use. FIPS 203 recommends ML-KEM-768 as the default parameter set unless that is impractical or a different security requirement applies. For ML-DSA, record whether ML-DSA-44, ML-DSA-65, or ML-DSA-87 is used and confirm signature length, public-key length, random seed, and intermediate-data handling requirements. For SLH-DSA, record the SHA2 or SHAKE parameter set, whether the small-signature or fast-signature variant is used, and the key-generation and signing randomness requirements.

Use cautious wording. The three standards say NIST will develop validation programs to test implementations for conformance to the algorithms in this standard, and the CMVP implementation guidance adds cryptographic algorithm self-test requirements for ML-KEM, ML-DSA, and SLH-DSA. That supports planning and evidence collection, but it does not justify saying that a product, library, or cloud service is validated unless the relevant certificate or module listing supports that exact scope.

For procurement, customer security reviews, and audit responses, verify the CAVP algorithm entry or CMVP module certificate against the algorithm, parameter set, module name, version, implementation environment, and approved-mode statement. If a supplier only provides roadmap language, test vectors, or an algorithm name, describe it as implementation evidence or migration status rather than validated FIPS evidence.

Treat a FIPS algorithm claim and a FIPS 140-3 module claim as related but different assertions. CAVP evidence supports a tested algorithm implementation; CMVP evidence supports a validated cryptographic module. A procurement file should show which claim the supplier is making and which public certificate or security policy supports it.

For each in-scope product or service, record the supplier name, product name, version, cryptographic module name, module certificate number, algorithm certificate number, operational environment, and the security service that uses the algorithm. If the supplier relies on a bound or embedded validated module, the evidence should identify that module by name, certificate number, and version rather than treating the larger product as automatically validated.

Collect evidence that a reviewer can verify without relying on marketing language. The core packet should include the supplier's FIPS claim, the public CAVP algorithm certificate where algorithm validation is claimed, the public CMVP module certificate where module validation is claimed, the FIPS 140-3 security policy, and a product-to-certificate mapping that names the exact product build and deployment environment.

Procurement clauses should define what counts as acceptable evidence and how conformance will be verified. For FIPS algorithm procurements, that means naming the certificate identifiers, requiring the supplier to disclose non-approved services or modes that may be present, and requiring notice when certificate status, product version, operating environment, module boundary, or cryptographic implementation changes.

The main review risk is accepting evidence that proves a different thing than the procurement claim. An AES certificate may support a specific algorithm implementation in a tested environment, but it does not by itself prove the purchased product is a FIPS 140-3 validated module or that every service in the product runs in an approved manner.

Before award, renewal, or reassessment, compare the certificate records and security policy against the actual deployment. Reopen the review when a supplier changes the module, adds an operating environment, changes firmware, moves a certificate to a different status, introduces a non-approved service, or claims a new algorithm without matching CAVP or permitted vendor-affirmed evidence.

The CMVP implementation guidance draws a clear line between certificate types. CAVP tests and validates cryptographic algorithm implementations; the algorithm validation certificate states the implementation name, implementation version, and tested operational environment.

CMVP tests and validates cryptographic modules. A module validation certificate states the validated cryptographic module name, version, and tested operational environment. That module-level evidence is separate from the algorithm certificate, even when the module uses CAVP-tested algorithms.

A validation certificate is a benchmark for the configuration and operational environment used during validation testing. For an algorithm implementation embedded in a module undergoing FIPS 140-3 testing, the guidance requires the algorithm implementation to remain unmodified and the CAVP-tested operational environment to be identical to, or fully included in, the module testing environment.

For software modules, the operating system, platform, processor, and any hypervisor details are part of the check. A certificate tested on one operating system or processor bit size should not be treated as evidence for another environment unless the official record and module evidence support that environment.

Use wording that names the exact evidence and stops at what it proves. A safe evidence statement identifies the certificate type, certificate number or listing, vendor, module or implementation name, version, operational environment, validation status, and the date the public listing was checked.

For procurement and customer responses, replace broad phrases such as FIPS compliant encryption with narrower wording. For example, state that a named algorithm implementation has a CAVP validation certificate, or that a named cryptographic module is listed by CMVP for a stated version and environment. Then add any approved-mode instructions, caveats, and deployment conditions that limit the claim.

FIPS 180-4 is the Secure Hash Standard for SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 adds the SHA-3 family: SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus the SHAKE128 and SHAKE256 extendable-output functions.

For a FIPS-approved algorithm decision, start by naming the exact function and use case. A message digest for digital signatures, an HMAC construction, a KDF, a DRBG, a post-quantum algorithm component, and a standalone SHAKE use can have different validation evidence even when the same hash family appears in the design.

The useful evidence is not a screenshot that says SHA-256 or SHA3-256 exists. Record the CAVP algorithm certificate or validation result for the exact implementation name, version, algorithm, parameters, and tested operational environment.

Keep that algorithm evidence separate from the module evidence. CAVP validates algorithm implementations; CMVP validates cryptographic modules under FIPS 140-3. A module claim needs the module certificate, approved-mode documentation, and security policy scope, not only a hash-algorithm certificate.

The main mistake is treating every FIPS 202 function as interchangeable. SHA-3 hash functions can appear as standalone functions or inside approved higher-level algorithms when the relevant testing path supports that use. CMVP implementation guidance is more restrictive for SHAKE128 and SHAKE256: outside algorithm standards that explicitly allow them, SHAKE functions are used as standalone algorithms.

A second mistake is importing a hash certificate into a higher-level claim without checking whether the higher-level algorithm has its own CAVP testing requirement or vendor-affirmed path. That matters for signatures, KDFs, DRBGs, and module approved-service listings.

Use FIPS 186-5 when the decision is about digital signature generation or verification for RSA, ECDSA, deterministic ECDSA, EdDSA, or HashEdDSA. The standard also states that DSA is no longer approved for digital signature generation, although DSA may be used to verify signatures generated before the implementation date.

The selection record should name the exact signature family, operation, parameters, key purpose, and approved hash or XOF relationship. For RSA, FIPS 186-5 permits signature generation or verification with modulus sizes at least 2048 bits, while CMVP implementation guidance explains how CAVP testing and Security Policy documentation handle sizes where CAVP testing is or is not available.

A useful evidence package starts with the standard citation but does not stop there. Keep the FIPS 186-5 algorithm decision, the CAVP algorithm-validation record, and the CMVP module claim as separate records that are linked only when the implementation name, version, parameters, and operating environment match.

For a CAVP check, capture the implementation name and version, vendor, certificate or validation-search entry, algorithm and mode, parameter set or modulus size, and tested operating environment. For a CMVP check, tie the signature service to the cryptographic module boundary, approved-mode service list, Security Policy, and any bound or embedded module caveats.

The first mistake is key reuse. FIPS 186-5 says digital signature key pairs must not be used for other purposes such as key establishment, and it repeats that RSA and ECDSA signature keys are signature-only. A key inventory should therefore show a signature-only purpose rather than a shared public-key bucket.

The second mistake is treating successful signature verification as the whole validation decision. For ECDSA and EdDSA, verifiers also need domain-parameter assurance; verifiers need public-key validity, claimed-signatory identity, and possession assurance before accepting a signature as valid. The third mistake is assuming conformance to FIPS 186-5 guarantees system security; the standard explicitly leaves implementation security and overall system assurance to the responsible implementer or authority.

FIPS 197 defines the Advanced Encryption Standard as a symmetric block cipher for protecting electronic data. The standard specifies three AES variants: AES-128, AES-192, and AES-256.

Each AES variant uses 128-bit data blocks. The suffix names the key length: 128, 192, or 256 bits. The 2023 update kept the algorithm intact while updating the publication, diagrams, terms, and editorial material.

No. FIPS 197 defines the AES algorithm; it is not a cryptographic module certificate. A product can use AES while still needing separate evidence about the implemented algorithm, module boundary, operational environment, approved services, and FIPS 140-3 validation status.

For algorithm evidence, check the CAVP record for the tested AES implementation and parameters. For module evidence, check the CMVP record and security policy for the validated module, certificate status, approved mode, services, and caveats.