How AES Works: The Block Cipher Behind Modern Encryption

Almost every encrypted thing you touch runs on AES. The HTTPS session loading this page, the encrypted volume on your laptop, the messages in your chat app, the backups in cloud storage. AES is the workhorse symmetric cipher, and it has held up under two decades of intense public scrutiny with no practical break. Understanding how it turns plaintext into ciphertext, and where the sharp edges are, is worth the effort.

AES, the Advanced Encryption Standard, is a symmetric block cipher. Symmetric means the same secret key encrypts and decrypts. Block cipher means it processes fixed-size chunks of data, 128 bits (16 bytes) at a time. NIST standardised it in FIPS 197 in 2001, selecting the Rijndael design from an open competition. The key can be 128, 192, or 256 bits, and that choice is the main knob you turn.

The state: a 4-by-4 grid of bytes

AES does not treat a block as a flat stream. It arranges the 16 input bytes into a 4-by-4 grid called the state. Every transformation in the cipher reads and rewrites this grid. All the arithmetic happens in a finite field (GF(2^8)), which is a fancy way of saying bytes are combined with special addition and multiplication rules that keep every result inside a single byte.

Encryption is a sequence of rounds, and each round mixes the state a little more. The number of rounds depends on the key size.

Key size	Rounds	Typical use
AES-128	10	General-purpose, TLS, disk encryption
AES-192	12	Less common, some compliance regimes
AES-256	14	High-assurance, long-term secrets

More rounds mean more mixing and a wider security margin. AES-256 is not simply "twice as strong" as AES-128; both are considered secure against classical attacks. The larger key mainly buys headroom against future advances and satisfies policies that mandate 256-bit keys.

What happens inside a round

Each full round applies four steps to the state, in order. Three of them scramble the data, and the fourth mixes in a piece of the key.

SubBytes (substitution)

Every byte in the state is replaced with another byte using a fixed lookup table called the S-box. This is a nonlinear step: there is no simple algebraic relationship between input and output. Cryptographers call this property confusion. It makes the connection between the key and the ciphertext hard to untangle, which is what stops an attacker from solving for the key with linear algebra.

ShiftRows (permutation)

The rows of the grid are rotated by different offsets. The first row stays put, the second shifts left by one byte, the third by two, the fourth by three. This moves bytes across columns so they interact with different neighbours in the next step.

MixColumns (permutation)

Each column of the state is transformed by mixing its four bytes together. A change to a single input byte now affects all four bytes of that column. ShiftRows and MixColumns together provide diffusion: after a couple of rounds, every output bit depends on every input bit and every key bit. Flip one bit of plaintext and roughly half the ciphertext bits change.

AddRoundKey (key mixing)

The state is combined (with XOR) with a round key, a 128-bit value derived from the main key by the key schedule. Each round uses a different round key. This is the only step that involves the secret, and it is what ties the whole permutation to your key.

The very first AddRoundKey happens before round one, and the final round skips MixColumns. Those details matter for a correct implementation, but the mental model holds: confuse with the S-box, diffuse with the shifts and mixing, then fold in key material, repeated 10 to 14 times.

Confusion and diffusion in one line

SubBytes hides the relationship between key and ciphertext (confusion). ShiftRows and MixColumns spread each input bit across the entire block (diffusion). Claude Shannon named these two goals in 1949, and AES is a clean textbook realisation of both.

The cipher is only half the story: modes

AES on its own encrypts exactly one 16-byte block. Real data is longer, so you need a mode of operation that describes how to chain blocks together. This choice is where most real-world cryptographic failures live.

The naive mode, ECB (Electronic Codebook), encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks, which leaks structure. The famous "ECB penguin" image, where the outline is still visible after encryption, is the standard illustration. Never use ECB for real data.

Two modes matter in practice.

Mode	Provides integrity	Needs	Notes
CBC	No	Random IV per message, separate MAC	Chains blocks, but silent on tampering
GCM	Yes	Unique nonce per message	Authenticated encryption, an integrity tag built in

CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block before encrypting, so identical blocks no longer look identical. It needs a random initialisation vector (IV) for each message. Its weakness is that CBC provides confidentiality only. It does nothing to detect tampering, and padding-related attacks (the padding oracle class) have broken careless CBC deployments repeatedly. To use CBC safely you must add a separate message authentication code and verify it before decrypting.

GCM (Galois/Counter Mode) is the modern default. It turns AES into a stream-like cipher using counter mode and produces an authentication tag alongside the ciphertext. On decryption, a wrong tag means the data was altered, and you reject it. This is authenticated encryption with associated data (AEAD), and it is what TLS 1.3 uses. The catch is the nonce.

The one GCM rule you cannot break

Never reuse a nonce with the same key in AES-GCM. Nonce reuse lets an attacker recover the authentication key and forge messages, and it can expose plaintext. Use a counter or a random 96-bit nonce from a strong generator, and rotate keys before you could ever wrap around.

How to use AES safely

Most people should never touch the round function. The goal is to call a vetted library correctly.

Prefer AES-GCM (or ChaCha20-Poly1305) over CBC. Choose an AEAD mode so integrity comes for free. If a library hands you raw CBC with no MAC, treat that as a red flag.
Let the library generate IVs and nonces. Do not hardcode them, do not reuse them, and do not derive them from a counter you might reset.
Pick 256-bit keys when policy or long-term secrecy demands it, otherwise 128 is fine. Both resist brute force. The choice is about compliance and margin, not day-to-day safety.
Derive keys properly. Never use a password directly as an AES key. Run it through a key derivation function like Argon2 or PBKDF2 first. See How Password Hashing Works.
Do not roll your own. Timing side channels, padding handling, and nonce management are where implementations die. Use a maintained library.

Weak or misused symmetric crypto shows up as real, tracked vulnerabilities. You can see how cipher and mode weaknesses surface as CVEs on our Exploit Intelligence dashboard, which is a useful reminder that the failures are almost always in how a cipher is wired up, not in the cipher itself.

Why AES has lasted

AES was designed in the open, standardised through a public competition, and has resisted every serious cryptanalytic effort since 2001. The best known attacks shave only a tiny margin off the theoretical key search and remain far out of practical reach. Even a large quantum computer, via Grover's algorithm, would at worst halve the effective key strength, which is why AES-256 is often recommended for data that must stay secret for decades. For a symmetric cipher, that is about as reassuring as it gets.

The lesson is that AES rarely fails. Deployments fail: a reused nonce, a missing MAC, a password used directly as a key, an IV that never changes. Get the mode and the key management right and the cipher will hold.

Following one block through the cipher

Tracing the path of a single block makes the round structure concrete. Picture 16 bytes of plaintext arranged into the 4-by-4 state. Before any round runs, AddRoundKey XORs the state with the first round key, so the attacker never sees the raw plaintext sitting in the state unmixed with key material.

Round one begins. SubBytes replaces all 16 bytes through the S-box, so every byte now depends nonlinearly on its original value. ShiftRows rotates the rows, moving those substituted bytes into different columns. MixColumns then blends each column so that all four bytes in a column influence one another. A single byte that entered the round now touches four positions after MixColumns. AddRoundKey folds in the next round key.

After the second round, that same original byte has spread across the entire state, because the bytes it influenced in round one were themselves moved and mixed again in round two. This rapid spread is the avalanche effect: flip one bit of the plaintext or the key and roughly half the ciphertext bits change, with no visible relationship between the input change and the output change. The rounds continue this way, and the final round applies SubBytes, ShiftRows, and AddRoundKey while omitting MixColumns, which keeps encryption and decryption symmetric. The result is a ciphertext block where every bit depends on every plaintext bit and every key bit.

The avalanche effect is what makes AES usable inside modes and constructions that assume a strong pseudorandom permutation. It is also why partial knowledge helps an attacker so little: learning some plaintext bits reveals nothing usable about the key, because the relationship between them is buried under layers of substitution and diffusion.

The key schedule: turning one key into many

Each round needs its own round key, and those come from the key schedule, sometimes called key expansion. The single key you supply, 128, 192, or 256 bits, is expanded into a longer sequence of round keys, one for the initial AddRoundKey and one for each round that follows. AES-128 expands into 11 round keys, AES-192 into 13, and AES-256 into 15.

The expansion is deterministic. It takes the previous words of the schedule, applies a small transformation to some of them (a byte rotation, a pass through the same S-box used in SubBytes, and an XOR with a round constant), then combines them to produce the next words. The round constant changes each round so that no two rounds derive an identical key from identical input, which prevents a class of symmetry attacks.

For a defender or a curious engineer, the important properties are these. The schedule is reversible in the sense that all round keys can be regenerated from the main key, so nothing extra needs to be stored. The larger key sizes feed more original key material into the schedule, which is part of why they carry more rounds. And the schedule reuses the S-box, so a hardware implementation that already has an S-box for SubBytes can share it, keeping the circuit small.

Why more key bits mean more rounds

AES-128 runs 10 rounds, AES-192 runs 12, and AES-256 runs 14. The extra rounds are there because a longer key adds mixing work to distribute the additional key material fully across the block. The round counts were chosen with a security margin above the point where known attacks lose traction, which is why even reduced-round academic attacks stay far from threatening the full cipher.

Decryption runs the rounds backward

Because AES is symmetric, decryption undoes each step in reverse order with inverse operations. SubBytes has an inverse S-box, ShiftRows shifts the other way, and MixColumns has an inverse mixing matrix. AddRoundKey is its own inverse, because XORing the same round key twice returns the original value, so the same step serves both directions with the round keys applied in reverse sequence.

This gives AES a clean symmetry, and it also explains a practical detail. In the counter-based modes that dominate modern use, such as CTR and GCM, decryption never calls the inverse operations at all. Those modes only ever encrypt a counter to make a keystream, then XOR it with the data, so both encrypting and decrypting a message use the forward AES function. That is one reason CTR-style modes are attractive in hardware: only the encryption path needs to exist.

AES in hardware: why it is so fast

Modern processors implement AES directly in silicon. On common desktop and server chips this is exposed through dedicated instructions (often called AES-NI) that perform a full round of the cipher in a single instruction. The effect is dramatic. Software AES that once cost many cycles per byte drops to a fraction of that, which is why full-disk encryption and TLS at scale impose so little overhead on current hardware.

Hardware AES brings a second benefit that matters for security. A careful hardware implementation runs in constant time, meaning it takes the same number of cycles regardless of the data or key values. That removes the timing side channels that plague naive software implementations, where table lookups in the S-box can leak information through cache behaviour. When you call a maintained crypto library on modern hardware, it uses these instructions and sidesteps that whole category of leak.

Property	Software AES (table-based)	Hardware AES (AES-NI)
Speed	Slower, many cycles per byte	Very fast, a fraction of a cycle per byte
Timing side channels	Possible through cache-timed table lookups	Constant-time, no data-dependent timing
Availability	Everywhere, pure code	Requires processor support
Best used for	Fallback where no hardware exists	Default on modern servers and laptops

How AES compares to other symmetric ciphers

AES is the default, and it is worth knowing what sits around it and why the alternatives exist.

Cipher	Type	Note
AES	Block cipher, 128-bit block	The global standard, hardware-accelerated, used in TLS, disk encryption, and more
ChaCha20	Stream cipher	Fast and constant-time in pure software, favoured where AES hardware is absent, paired with Poly1305 for AEAD
3DES	Block cipher, 64-bit block	Legacy, slow, and its small block invites birthday-bound attacks on large data; being retired
DES	Block cipher, 56-bit key	Broken by brute force decades ago, of historical interest only
Blowfish	Block cipher, 64-bit block	Older design, small block, largely superseded by AES and its successor Twofish

The practical takeaway is that AES and ChaCha20-Poly1305 cover nearly every modern need. AES wins where hardware acceleration is present, which is most servers and laptops. ChaCha20-Poly1305 wins on hardware without AES instructions, such as some mobile and embedded targets, where its software speed and constant-time behaviour shine.

Common mistakes and misconceptions

"AES-256 is twice as strong as AES-128." Both resist brute force by an overwhelming margin. The 256-bit key adds headroom and satisfies policies that mandate it, and it is the sensible choice for secrets that must survive for decades. For everyday confidentiality, AES-128 is already far beyond practical attack.

"Encrypting with AES makes my data safe." The cipher is only part of the system. A reused nonce in GCM, a missing authentication tag in CBC, or ECB mode chosen by accident can each break a deployment while AES itself remains untouched. The mode and the key management decide real-world safety.

"A password is a key." A human password is low in entropy and the wrong length for an AES key. Feeding it directly into AES is a common and serious mistake. Passwords must pass through a key derivation function such as Argon2 or PBKDF2, which stretches and salts them into a proper key. See How Password Hashing Works.

"ECB is fine for small data." ECB leaks whenever plaintext blocks repeat, and small structured data repeats more than people expect. There is no size at which ECB becomes the right choice for confidential data.

"AES is quantum-proof, so I need nothing else." A large quantum computer running Grover's algorithm would halve the effective key strength, which is why AES-256 is recommended for long-term secrets. Symmetric AES holds up far better against quantum attack than the asymmetric algorithms used for key exchange, and those asymmetric parts are where post-quantum migration is focused.

The failure is almost always the wiring

When AES-protected data is exposed, the cipher is rarely the reason. Look first at the mode, the nonce or IV handling, whether an authentication tag was present and checked, and how the key was derived and stored. Two decades of scrutiny have left AES itself sound, so the productive place to audit is everything wrapped around it.

Frequently asked questions

Is AES symmetric or asymmetric? AES is symmetric, meaning the same secret key encrypts and decrypts. Asymmetric systems like RSA and elliptic-curve cryptography use a public and private key pair and are typically used to exchange or protect the symmetric key that AES then uses for bulk data. See Symmetric vs Asymmetric Encryption.

What is the difference between AES-128 and AES-256? The key length and, as a consequence, the number of rounds: 10 rounds for AES-128 and 14 for AES-256. Both are secure against classical brute force. AES-256 adds margin and is the usual choice for long-lived secrets or where policy requires 256-bit keys.

Why is AES-GCM preferred over AES-CBC? GCM is an authenticated mode. It produces an authentication tag that detects any tampering with the ciphertext, and it decrypts in parallel. CBC provides confidentiality only, needs a separate message authentication code to be safe, and has a history of padding-oracle failures when integrity is not checked. For new designs, an AEAD mode like GCM is the right default.

Has AES ever been broken? There is no practical break of full AES. The best published cryptanalysis reduces the theoretical key-search effort by a tiny fraction and remains far outside any feasible computation. The realistic risks are implementation flaws and misuse, such as nonce reuse, rather than a weakness in the cipher.

Can I use a password as an AES key directly? No. Run the password through a key derivation function such as Argon2, scrypt, or PBKDF2 first. These add a salt and deliberate computational cost, producing a full-length key and resisting brute-force guessing of the password.

What block size does AES use? AES always uses a 128-bit (16-byte) block, regardless of key size. The Rijndael design it came from supported other block sizes, and the standardised AES fixed the block at 128 bits while allowing three key sizes.

Does AES protect against tampering? Only in an authenticated mode. Plain AES in a confidentiality-only mode like CBC or CTR hides content and does nothing to detect modification. Use an AEAD mode such as AES-GCM, or add and verify a separate message authentication code, to get integrity.

Why does the final round skip MixColumns? Omitting MixColumns in the last round keeps the encryption and decryption paths structurally symmetric, which simplifies implementation. It removes no security, because the preceding rounds have already achieved full diffusion across the block. The mental model of confusion then diffusion then key mixing still holds for every round that carries the heavy lifting.