Search every question across sub-FAQs

Do not reuse signature keys. 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.

Successful signature verification is not 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. Conformance to FIPS 186-5 also does not guarantee system security; the standard 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.

FIPS 197 does not select a mode for an application. NIST specifies modes in the SP 800-38 series: SP 800-38A covers confidentiality modes such as CBC, CFB, OFB, CTR, and ECB; SP 800-38D covers GCM authenticated encryption; and other parts cover storage, key wrapping, and additional uses. The service design, current NIST guidance, protocol, and module certificate must support the chosen mode.

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.

Start with the security service and controlling protocol, not the AES label. Decide whether the design needs confidentiality only, authenticated encryption, storage encryption, or key wrapping; identify the NIST mode and protocol profile that permits that service; then record the AES key size, mode parameters, key source, implementation version, and deployment environment.

The system owner or cryptographic architect should document the selection. The implementation owner should map the running code or hardware to the CAVP entry, and the assurance or procurement owner should map the deployed service to the CMVP certificate and Security Policy when a FIPS 140-3 claim is required. Retain the decision record, certificate URLs and check dates, approved-mode instructions, configuration evidence, and test results.

Reopen the review when the AES library or hardware implementation changes, the mode or key size changes, nonce or IV generation changes, firmware or operating environment changes, the module boundary changes, or a CAVP or CMVP listing changes status. A protocol update or new NIST transition rule can also change whether the recorded choice remains acceptable.