AES requirements under FIPS 197

FIPS 197 defines AES as a symmetric block cipher. The standard specifies AES-128, AES-192, and AES-256, each with a 128-bit block size; the suffix names the key length. Other Rijndael block sizes or key lengths are outside the AES configurations adopted by FIPS 197. The standard became effective on May 26, 2002. NIST's May 9, 2023 update added diagrams and editorial improvements but made no technical change to the algorithm.

FIPS 197 applies to information systems used or operated by US federal agencies, contractors, or other organizations on an agency's behalf. A private organization may adopt it voluntarily or through a contract or policy. The system owner should record which instrument makes FIPS 197 relevant; the algorithm name alone does not create a universal legal duty.

Treat FIPS 197 as the algorithm specification, not as a complete encryption design. The standard says the algorithm may be implemented in software, firmware, hardware, or combinations of them and shall be used with a FIPS-approved or NIST-recommended mode of operation. The separate mode or protocol specification controls matters such as initialization values or nonces, padding, authentication tags, error handling, and whether the construction provides confidentiality, authentication, or both.

A correct AES implementation is not the same thing as a validated cryptographic module. FIPS 140-3 is the module security standard, and CMVP validation applies to a defined cryptographic module boundary, security level, operating environment, services, self-tests, lifecycle evidence, and approved security functions.

Procurement language should therefore avoid shortcuts such as "FIPS 197 certified product" or "AES means FIPS validated." Safer wording names the algorithm, the mode, the cryptographic module or library, and any relevant CMVP or CAVP evidence separately.

Keep the evidence narrow and technical. The product or system owner records the required service and allowed claim; the implementer records the AES configuration, mode, key handling, library or hardware path, and release; the assessor or buyer checks that evidence against any CAVP and CMVP records. The completed review should show why the selected mode fits the service and whether the claim is algorithm-level, mode-level, or module-level.

For implementation changes, treat the evidence as versioned. A library upgrade, hardware acceleration change, operating-environment change, module boundary change, or mode change can make older test or certificate evidence too broad for the current release. The AES key size alone cannot answer whether the mode, nonce construction, tag length, key lifecycle, or protocol profile is acceptable.

Review this checklist before publishing an AES claim, accepting supplier evidence, or responding to an audit question. Each item should be answered with a named source, record, or certificate rather than a general statement that AES is approved.

Most AES FIPS 197 errors cross claim boundaries. Name what was selected, tested, or validated, and remove wording that implies broader assurance than the source supports.