--- title: "AES (FIPS 197) - How to Use AES Safely" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197" author: "Sorena AI" description: "Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "AES FIPS 197" - "Advanced Encryption Standard" - "AES-128 AES-192 AES-256" - "FIPS approved encryption" - "AES implementation guide" - "AES modes of operation" - "AES key management" - "AES evidence pack" - "FIPS 140-3 approved mode AES" - "GLOBAL compliance" - "FIPS 197" - "AES" - "Symmetric encryption" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # AES (FIPS 197) - How to Use AES Safely Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. *Implementation guide* *GLOBAL* ## FIPS Crypto Algorithms AES (FIPS 197) AES is the FIPS-approved block cipher for confidentiality, but most failures come from unsafe use around the cipher. This page explains what FIPS 197 specifies and how to use AES safely in real systems. FIPS 197, updated on 9 May 2023 as FIPS 197 upd1, specifies the Advanced Encryption Standard. It defines three members of the Rijndael family: AES-128, AES-192, and AES-256. All use a fixed 128-bit block size, and the key length determines the variant. The practical engineering problem is not the round function itself. It is safe usage: approved mode selection, IV or nonce rules, key handling, and evidence that your implementation matches your assurance claims. ## What FIPS 197 specifies and what it leaves to other guidance FIPS 197 is the algorithm standard. It defines AES as a symmetric block cipher with a fixed 128-bit block and key lengths of 128, 192, or 256 bits. It does not by itself specify a secure application profile for files, APIs, or network protocols. The standard says AES shall be used with a FIPS-approved or NIST-recommended mode of operation. That means teams have to govern the full bundle: AES plus mode plus IV or nonce rules plus key lifecycle. - Variants: AES-128, AES-192, AES-256 - Block size: 128 bits - Implementations may be software, firmware, hardware, or a combination - Mode selection and object identifiers are handled through related NIST resources such as CSOR ## Safe AES usage means controlling the full bundle Most AES failures are not failures of the cipher. They are failures of mode choice, IV reuse, weak key separation, or sloppy error handling. Treat AES usage as a controlled bundle. If any one part of the bundle is uncontrolled, the overall design can fail even when the algorithm is correct. - Use only approved or recommended modes that match the protocol and threat model - Define IV or nonce generation rules in code and tests, not only in documentation - Separate keys by purpose so encryption keys do not become general-purpose secrets - Make failure handling explicit so padding, tag, or decryption errors do not leak useful signals ## Implementation discipline that reduces audit and validation pain AES deployments go wrong when secure defaults are optional or when different runtimes quietly pick different configurations. The safest pattern is to publish a narrow approved-configuration set per supported product version and environment. That matters even more in FIPS 140-3 contexts, because the approved-mode story must be consistent across documentation, test evidence, and runtime behavior. - Pin libraries, firmware, accelerators, and build flags for the validated or reviewed configuration - Make configuration drift visible with manifests or startup checks - Retain test vectors, known-answer tests, and integration evidence for each supported build - Document where AES is used, for what purpose, and under which operational constraints ## What evidence is worth retaining Even if you are not pursuing immediate module validation, customers and internal reviewers will ask the same questions: where is AES used, what parameters are allowed, and how do you prevent misuse. Build the evidence pack as a byproduct of engineering work rather than as a late-stage audit exercise. - Crypto inventory entry showing service, mode, key size, and owner - Configuration evidence such as build flags, manifests, and runtime policy - Verification artifacts such as known-answer tests and interoperability tests - Key-management records covering generation, storage, rotation, and destruction - Change-control history for algorithm, mode, or dependency updates *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS Crypto Algorithms AES (FIPS 197) as a cited research workflow Research Copilot can take FIPS Crypto Algorithms AES (FIPS 197) from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms AES (FIPS 197)](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms AES (FIPS 197) and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms AES (FIPS 197). ## Primary sources - [FIPS 197 upd1: Advanced Encryption Standard (AES)](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Primary source for AES definition, key sizes, and the requirement to use approved or recommended modes. - [NIST AES project page](https://csrc.nist.gov/projects/aes?ref=sorena.io) - Official AES project resources and examples. - [Computer Security Objects Register](https://csrc.nist.gov/projects/csor?ref=sorena.io) - Official source for AES object identifiers and associated parameters. - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Context for how AES is treated inside validated modules and approved-mode claims. ## Related Topic Guides - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197