AES, step by step — and what each step is for

The 16 input bytes in₀…in₁₅ are loaded column by column: s[r,c] = in[r + 4c] (FIPS 197 §3.4). So bytes 0,1,2,3 are column 0; bytes 4,5,6,7 are column 1. AES is specified on an array of 32-bit words, and words are columns here (§3.5). The convention matters because ShiftRows moves bytes between columns along each row, and MixColumns then mixes each column — the two together are what spread one byte across the block. Load a block row-by-row by mistake and you have written a different cipher that produces plausible-looking 16-byte output.

The S-box is the composition of two maps. First x ↦ x⁻¹ in GF(2⁸), which is highly nonlinear (degree-7 algebraic normal form) — exactly what a substitution layer needs to resist linear and differential cryptanalysis. Then a fixed affine map over GF(2), which is linear and adds no security by itself. Why bother with the second step, if it is linear? Because the plain inverse has fixed points (1 ↦ 1) and a rigid algebraic structure that makes attacks like interpolation and the algebraic "XSL" family easier to formulate; composing it with an affine map chosen so that the S-box has no fixed points and no inverse-fixed points, and a maximum-difference/maximum-linear-bias profile of 4/32, removes that structure at negligible cost. Security comes from the inverse; hygiene comes from the affine map.

A permutation of the 16 bytes (as ShiftRows is) rearranges information without ever creating new values: a single nonzero byte stays a single nonzero byte, and after any number of rounds only 16 distinct values have appeared. MixColumns instead treats each 4-byte column as a polynomial over GF(2⁸) and multiplies it by the fixed matrix [[02,03,01,01],[01,02,03,01],[01,01,02,03],[03,01,01,02]] (§5.1.3, §4.3). One input byte becomes four different output bytes, so a difference in one byte is spread across the whole column. Combined with ShiftRows, which moves the resulting column's bytes into four different columns, one byte reaches all 16 bytes after two rounds. MixColumns is invertible (that matrix has an inverse over GF(2⁸) — the decryption matrix [[0e,0b,0d,09],…]), so it is a bijection on the 128-bit block, but it is not a permutation of the individual bytes.

Confusion means the relationship between the key and the ciphertext is complicated; AES gets it from the S-box (a key-XORed byte then jumps to an unrelated value) and from the key schedule's RotWord/SubWord/Rcon. Diffusion means a change to one input bit spreads everywhere; AES gets it from ShiftRows + MixColumns. The exact spread, and the reason we can state it precisely, is that both layers are linear over the byte-group structure (counting a round as the full round function, MixColumns included): after 1 round a single flipped input byte has become 4 differing bytes (its column, after MixColumns); after 2 rounds all 16 bytes differ, because ShiftRows has moved that column's bytes into four distinct columns and MixColumns has re-expanded each of them. So "every input byte influences every output byte after 2 rounds" — the panel above measures this on the page's own core. The remaining 8–12 rounds are the margin that turns a linear spreading result into resistance to differential, linear and integral cryptanalysis.

Nobody has found a practical attack on the cipher itself. The exhaustive key search is 2¹²⁸, 2¹⁹² or 2²⁵⁶, and the best known cryptanalysis — biclique key recovery against all 14 rounds of AES-256, but at 2²⁵⁴·⁴ work, and integral/square attacks on step-reduced variants — does not threaten any real key size. Related-key attacks (Biryukov–Khovratovich, 2009) break AES-256 badly, but only under a key-derivation model that well-designed protocols do not use. Related-key and "chosen-key" results are discussed in the literature because they say something about the design's margin, not because they apply to TLS. What actually breaks deployed AES is never the round function:

• Side channels. A table lookup indexed by a secret-dependent byte leaks through the cache. Bernstein's 2005 attack recovered an AES key from a network server by timing cache misses; the "T-table" implementations that dominated the 2000s are exactly what make this possible. Constant-time bitslicing and AES-NI exist for this reason.
• Fault attacks. Corrupt one byte of the state during round 8 or 9 with a voltage glitch or a laser, and the resulting faulty/valid ciphertext pair reveals key bytes with a handful of tries. Relevant mainly to smart cards and embedded devices.
• Bad modes and protocols. ECB leaks structure; CBC without a MAC is malleable by an active attacker; a padding oracle turns a CBC decryption error into a plaintext-recovery oracle (BEAST, Lucky 13, POODLE). These are the attacks behind most real-world AES failures.
• Bad key management. A 128-bit key derived from a password is a password. Weak entropy, key reuse across sessions, and nonce reuse in GCM are all more common than any of the above.

Rcon[i] = [xi−1, {00}, {00}, {00}] in GF(2⁸) (§5.2). Since x is the byte {02}, xⁱ⁻¹ is just xtime applied i−1 times: {01}, {02}, {04}, {08}, {10}, {20}, {40}, {80}, {1b}, {36}. The ninth one is the giveaway — {80} doubled is {100}, which reduces modulo 0x11B to {1b}. The index starts at 1 because Rcon[0] would be {01}, the same as the identity, and the round constants only ever enter at i mod Nk = 0 — there are at most ⌈4(N_r+1)/N_k⌉ − 1 = N_r of them, so ten values suffice for the 256-bit case and seven for 128-bit.

You can — that is what a substitution-permutation network buys you, and it is roughly what AES with 14 rounds already is. But iterating a cipher with the same key (a "cascade") does not multiply security the way you would hope: the composition of two ciphers over the same key space is still a map over that key space, so double-AES has a meet-in-the-middle attack at 2¹²⁸ instead of the 2²⁵⁶ you asked for, and triple-DES (2×56 = 112-bit effective) is the textbook demonstration. Running AES-256 twice does not give you 512-bit security; the practical answer is AES-256 with a good mode.