FIPS-approved cryptographic algorithms FAQ

For this topic, FIPS-approved means the algorithm or technique is specified in a FIPS or NIST recommendation, adopted in one, or included in the NIST-approved security functions list used for FIPS 140-3. That status is about the algorithm or technique, not a blanket approval of every product, protocol, cloud service, library build, key size, mode, or configuration that mentions it.

A useful algorithm record should name the standard, the algorithm family, the exact mode or parameter set, the intended use, and the evidence source. For example, AES is a FIPS-approved block cipher, but FIPS 197 also says AES is used with a FIPS-approved or NIST-recommended mode of operation.

No. CAVP validation is evidence that a specific cryptographic algorithm implementation passed algorithm testing. CMVP validation is about a cryptographic module meeting FIPS 140-3 requirements for a defined module boundary, tested operational environment, roles, services, self-tests, security policy, and other module requirements.

In a procurement or audit file, keep these artifacts separate. A CAVP certificate can support the algorithm implementation evidence for a module, but it does not by itself prove that the delivered product is a FIPS 140-3 validated cryptographic module or that the product is operating in approved mode.

Be careful. FIPS 140-3 implementation guidance says the FIPS 140-3 and SP 800-140 series do not address protocols as protocols. The approved-mode question is whether the module uses approved or allowed cryptographic algorithms and schemes, such as AES, ECDSA, KDFs, key-agreement schemes, or key-transport schemes, in the way permitted for the module's approved services.

For protocol claims, write the evidence around the cryptographic functions actually used by the module. For example, a TLS claim may require checking the KDF, cipher suite components, key agreement, certificate signature algorithms, random bit generation, and whether those services are listed as approved services in the module Security Policy.

Use the algorithm standard for the primitive, then check CMVP and CAVP evidence for the implementation and module. FIPS 197 covers AES; FIPS 180-4 covers SHA-1 and the SHA-2 family; FIPS 202 covers SHA-3 hash functions and SHAKE extendable-output functions; FIPS 186-5 covers DSA, ECDSA, EdDSA, and RSA signature requirements.

The key operational point is specificity. A claim such as AES, SHA, or FIPS signatures is not enough. The record should identify the mode or scheme, key length or digest length, approved use, implementation validation, and whether the module's approved services actually call that implementation.

Treat FIPS 203, FIPS 204, and FIPS 205 as algorithm standards, not automatic product approvals. FIPS 203 specifies ML-KEM for key establishment; FIPS 204 specifies ML-DSA for digital signatures; FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. Each claim still needs implementation evidence, parameter-set choices, module boundary evidence, and approved-mode treatment where FIPS 140-3 validation is relevant.

For migration planning, do not state that a system is post-quantum compliant because a roadmap names ML-KEM or ML-DSA. The defensible record identifies which algorithm standard is used, which parameter set is selected, where the algorithm runs, how keys or signatures are generated, and what CAVP or CMVP evidence is available for the implementation and module.

Sometimes, but the distinction is narrow. CMVP guidance says non-approved security functions cannot be used in approved mode. It also recognizes that a non-approved cryptographic algorithm may appear in approved mode only when it is not used as a security function, does not meet FIPS 140-3 requirements, and is clearly documented as providing no claimed security.

This matters for libraries, diagnostics, interoperability code, and internal obfuscation. If a non-approved algorithm is exposed as encryption, key agreement, key transport, message authentication, digest generation, signature generation, signature verification, or another security function, it should not be treated as harmless just because the module also contains approved algorithms.

Keep evidence that lets another reviewer reconstruct the claim without relying on marketing shorthand. The packet should show the algorithm standard, the implementation validation evidence, the module validation evidence if a module claim is made, and the product or service configuration that uses the approved service.

For customer-facing or procurement language, the minimum useful file is the exact claim text, the source standard, any CAVP certificate references, the CMVP certificate and Security Policy when applicable, the module version and operational environment, and the owner who approved the wording.