FIPS Crypto Algorithms
Choose FIPS cryptographic algorithms and distinguish algorithm approval, testing, and FIPS 140-3 module validation for defensible implementation claims.
Choose the standard for the cryptographic service you need, then separate the algorithm, tested implementation, validated module, and deployed product claims.
Each publication's applicability clause controls. FIPS requirements can cover US federal agency systems and systems operated for an agency under contract; national-security and statute-specific exclusions differ by publication. Contracts, procurement rules, and organizational policies can adopt the same standards elsewhere. Using AES, SHA, RSA, or a does not make a product FIPS 140-3 validated.
Records the required cryptographic service, exact algorithm, mode or parameter set, protocol use, and migration assumptions.
Connects source code or hardware, version, platform, tested capabilities, record, and change history.
Checks the CMVP certificate and Security Policy against the delivered release, module boundary, environment, approved service, and procurement requirement.
Name the service, FIPS publication, algorithm, mode or parameter set, supporting functions, and allowed use. A standard specifies the primitive; it does not decide whether a protocol use is suitable or validate a product.
Match the public algorithm-validation record to the implementation name, version, tested parameters, and operational environment. ACVP is the testing protocol and ACVTS is the test system; neither is a separate product certificate.
Confirm the module certificate, Security Policy, boundary, approved services, service indicators, operational environment, certificate status, and delivered configuration before making a FIPS 140-3 claim.
New to the topic? Start by identifying the cryptographic service and claim type. If those are already known, jump to the algorithm family, validation evidence, procurement, transition, or comparison guide you need.
Decide what cryptographic service is needed, whether the requirement comes from federal scope, contract, procurement, or internal policy, and whether the intended claim concerns an algorithm, implementation, module, or deployment.
Choose the exact AES, hash, signature, KEM, KDF, MAC, or key-management path and record the mode, parameter set, supporting functions, and usage limits.
Keep algorithm testing, ACVP/ACVTS test mechanics, CMVP module validation, approved-service operation, protocol configuration, and supplier claims at their correct evidence boundaries.
Track approved, disallowed, deprecated, withdrawn, and legacy-use decisions at the algorithm, validation-program, module, procurement, and deployed-use layers without inventing a single universal status.
Compare primitives by cryptographic service, parameter and integration constraints, interoperability, evidence availability, and migration impact. A newer algorithm is not necessarily a drop-in replacement.
"CAVP addresses the testing of Approved Security Functions"
"security requirements for cryptographic modules"
"Only algorithm implementations that are validated by NIST"
"FIPS 186-4 remains in effect for a period of one year"
"AES-128, AES-192, and AES-256"
"Permutation-Based Hash and Extendable-Output Functions"
"not approved for use in a stand-alone fashion"
"Module-Lattice-Based Digital Signature Standard"
"This standard approves 12 parameter sets"
Next steps
Build an algorithm inventory with separate records for AES, hash, signature, KEM, and module-validation evidence.
Research FIPS algorithm, validation, and transition questions with cited NIST-source outputs.
Keep algorithm inventories, certificate references, module-boundary notes, and review records in one governed system.
Review your algorithm inventory, validation evidence model, and post-quantum migration questions.