Skip to main content
  1. Index/

AES (Advanced Encryption Standard)

AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.

A block cipher operating on raw 128-bit blocks is not directly useful for encrypting arbitrary-length data or for providing authentication. Modes of operation compose AES into schemes that handle arbitrary data and provide additional security properties. The dominant mode in modern deployments is AES-GCM (Galois/Counter Mode), an AEAD (Authenticated Encryption with Associated Data) construction that simultaneously encrypts data and produces a 128-bit authentication tag, using a keystream generated by running AES in counter mode. AES-GCM provides confidentiality, integrity, and authenticity in a single pass, is parallelisable (unlike CBC), and is hardware-accelerated on every modern CPU via AES-NI and CLMUL instructions. It is the cipher for TLS 1.3 (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256), IPsec ESP, MACsec, WireGuard (via ChaCha20-Poly1305 as an alternative), and LUKS2. The critical operational constraint of AES-GCM is nonce uniqueness: AES-GCM is catastrophically broken if the same (key, nonce) pair is ever used to encrypt two different plaintexts — the authentication tag collapses and the keystream is exposed, allowing an adversary to recover plaintext and forge messages. The 96-bit GCM nonce must be unique per encryption with a given key; for high-throughput systems, nonce exhaustion (2^32 messages at 64-byte blocks before the 2^32 block limit becomes a concern) or random nonce collision (birthday-bound at ~2^48 with random 96-bit nonces) are real operational limits that drive AES key rotation policies. AES-GCM-SIV (RFC 8452) mitigates nonce-misuse risk by deriving a per-message subkey, providing security even if nonces are accidentally reused, at a modest performance cost. AES-CBC (Cipher Block Chaining) is a legacy mode without built-in authentication, historically dominant in TLS 1.2 and disk encryption but deprecated in TLS 1.3 and superseded by AES-XTS and AES-GCM for new deployments. AES-XTS (XEX-based Tweaked-codebook mode with ciphertext Stealing) is the standard mode for disk and storage encryption: it takes a 128-bit “tweak” (the disk sector number) as a second input, producing independent, parallelisable encryption per sector without an IV or authentication tag — the performance profile is right for block devices, though the absence of authentication means AES-XTS provides confidentiality only, not integrity.

AES appears at every layer of the infrastructure stack in this glossary. TLS 1.3 uses AES-256-GCM or ChaCha20-Poly1305 for record encryption. LUKS2 encrypts block devices with AES-XTS-512 (two 256-bit subkeys) by default, selectable to AES-XTS-256. TDX and SEV-SNP encrypt confidential VM memory with AES-128-XTS (TDX) and AES-128-XEX (SEV) using per-VM keys managed by the CPU memory controller, at hardware speed with no software involvement. MACsec encrypts Ethernet frames with AES-GCM-128 or AES-GCM-256. IPsec ESP uses AES-GCM-128 or AES-GCM-256. HSMs use AES-256 for key wrapping (encrypting exported key material under a key-encryption key stored in the HSM). ML-KEM, ML-DSA, and SLH-DSA all use AES (or SHAKE) internally for pseudorandom generation in their parameter sets. Against quantum computers, AES is substantially more resilient than the asymmetric algorithms it works alongside: Grover’s algorithm provides a quadratic speedup for brute-forcing symmetric keys, halving the effective key length — AES-128 provides 64-bit quantum security (marginal), AES-256 provides 128-bit quantum security (considered safe). This is why the PQC transition replaces asymmetric algorithms entirely (RSA, ECDSA, ECDH → ML-KEM, ML-DSA) while retaining AES-256 as the symmetric layer, simply increasing key sizes where AES-128 was previously used.

Related

SHA (Secure Hash Algorithm)

SHA (Secure Hash Algorithm) is the name given to a series of cryptographic hash function families standardised by NIST under FIPS 180 and FIPS 202. Three generations exist with fundamentally different design lineages. SHA-1 (1995, FIPS 180-1) produces a 160-bit digest and is fully broken for collision resistance: the SHAttered attack (Google and CWI Amsterdam, 2017) produced a chosen-prefix collision — two different PDF files with identical SHA-1 hashes — using approximately 9.2 × 10^18 SHA-1 operations, within practical reach of well-resourced attackers. SHA-1 must not be used for any security purpose; it persists only in legacy Git object identifiers (SHA-1 is being phased out in Git’s object store in favour of SHA-256 under the sha256 object format) and in TOTP’s HMAC-SHA-1 inner construction (where collision resistance is not the relevant security property, but migration to SHA-256 variants is still recommended). SHA-2 (2001, FIPS 180-2 and subsequent revisions) is the Merkle-Damgård family that includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 and SHA-512 are the two variants in universal production use; the others serve niche roles. SHA-3 (2015, FIPS 202) is the Keccak sponge construction — structurally independent of SHA-2 — providing algorithm diversity and including fixed-output variants (SHA3-256, SHA3-512) and extendable output functions (SHAKE128, SHAKE256).

HMAC (Hash-based Message Authentication Code)

HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.

Hash Function (Cryptographic Hash Function)

A cryptographic hash function maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length digest (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. Preimage resistance: given a digest h, it is computationally infeasible to find any input m such that H(m) = h. Second preimage resistance: given an input m1, it is computationally infeasible to find a different input m2 such that H(m1) = H(m2). Collision resistance: it is computationally infeasible to find any pair (m1, m2) with m1 ≠ m2 such that H(m1) = H(m2). Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.