AES Encryption - Unbreakable Algorithm, Breakable Systems

Background

What Is AES Encryption

The Advanced Encryption Standard is a symmetric block cipher that operates on fixed 128-bit blocks of data. "Symmetric" means the same key locks and unlocks the data — unlike RSA or elliptic-curve schemes where encryption and decryption use different keys. AES accepts key lengths of 128, 192, or 256 bits, with the number of internal transformation rounds scaling accordingly: 10 rounds for AES-128, 12 for AES-192, and 14 for AES-256.

Each round applies four operations in sequence. SubBytes performs a nonlinear byte substitution through a fixed lookup table (the S-box), breaking algebraic relationships between plaintext and ciphertext. ShiftRows cyclically shifts the bytes in each row of the 4×4 state matrix by different offsets, spreading byte influence across columns. MixColumns multiplies each column by a fixed polynomial in GF(2⁸), diffusing single-byte changes across the entire column. Finally, AddRoundKey XORs the state with a round-specific subkey derived from the master key through a key schedule. The final round omits MixColumns — a design choice that makes the cipher's forward and inverse paths structurally symmetric, simplifying hardware implementations.

AES emerged from a NIST competition launched in 1997 to replace the aging Data Encryption Standard. DES, with its 56-bit key, had become vulnerable to brute-force attacks — the EFF's "Deep Crack" machine cracked a DES key in under 23 hours in 1998. Triple-DES patched the key length problem but tripled the computational cost. The Rijndael algorithm, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, won the competition in 2001 on the strength of its security margin, performance across platforms, and elegant mathematical structure.

Why AES Is Trusted Globally

AES holds a rare position in cryptography: it is trusted simultaneously by organizations whose threat models are mutually incompatible. The U.S. National Security Agency approved AES-256 for protecting TOP SECRET information. Global financial networks — Visa, Mastercard, SWIFT — rely on AES to secure transactions worth trillions of dollars annually. TLS, the protocol encrypting virtually all web traffic, defaults to AES-based cipher suites.

This trust rests on several pillars. The NIST standardization process was public and adversarial by design; the global cryptographic community spent years attacking each candidate before Rijndael was selected. In the two decades since, no practical attack against full-round AES has been published. The best known theoretical attacks — biclique attacks by Bogdanov, Khovratovich, and Rechberger (2011) — reduce the effective security of AES-128 from 2¹²⁸ to roughly 2¹²⁶·¹ operations, a margin so thin it remains firmly in the domain of academic curiosity.

Modern processors include dedicated AES-NI instructions that execute AES rounds in hardware, achieving throughputs exceeding 4 GB/s on commodity CPUs. This eliminates the performance penalty that historically pushed developers toward weaker but faster alternatives — and, critically, it removes timing variations that software implementations can leak through cache access patterns.

Is AES Really Secure?

Here is the uncomfortable truth: AES itself has never been broken in any practical sense, but systems built on AES are compromised routinely. The distinction matters. When a padded CBC implementation leaks timing information, or when a developer encrypts a database in ECB mode, the fault is not in the fifteen-round substitution-permutation network. It is in the choices surrounding it.

Cryptographers describe this gap with the phrase "attacks don't get better, they get applied." AES provides a secure primitive — a building block. But a building block used incorrectly produces a fragile structure. The mode of operation determines how AES processes data longer than a single 16-byte block. The initialization vector (IV) or nonce introduces randomness so that encrypting the same message twice does not produce identical ciphertext. Key management governs how keys are generated, stored, rotated, and destroyed.

Get any of these wrong, and AES becomes a locked vault with the combination taped to the door.

Potential Vulnerabilities: A High-Level Overview ECB Mode Pattern Leakage

Electronic Codebook mode is the simplest way to use a block cipher: split the plaintext into 16-byte blocks, encrypt each one independently with the same key. The problem is fundamental — identical plaintext blocks always produce identical ciphertext blocks. Any structure or repetition in the input survives encryption intact. The most famous demonstration is the "ECB penguin": a bitmap image encrypted with AES-ECB retains the visible outline of the original image because large regions of identical pixel values map to identical ciphertext regions.

IV Reuse Issues

An Initialization Vector is a value combined with the key to ensure that encrypting the same plaintext twice produces different ciphertext each time. When an IV is reused with the same key, this guarantee collapses. In counter (CTR) mode, IV reuse means two messages are encrypted with an identical keystream — XOR the two ciphertexts together, and the keystream cancels, leaving only the XOR of the two plaintexts. From there, frequency analysis, known-plaintext cribs, or structural assumptions can recover both messages.

Padding Oracle Attacks (CBC Mode)

Block ciphers require input lengths that are exact multiples of the block size. When a message does not align, padding schemes like PKCS#7 fill the gap. In Cipher Block Chaining mode, if a server reveals whether decrypted padding is valid — through an error message, an HTTP status code, or even a measurable timing difference — that single bit of information becomes a side channel. An attacker who can submit modified ciphertexts and observe the server's response can recover the entire plaintext without ever learning the key.

Deep Technical Explanations

ECB Mode Vulnerability

ECB's failure is deterministic encryption. For a given key K, the encryption function EK is a fixed permutation over the set of all 128-bit blocks. If P1 = P2, then EK(P1) = EK(P2) — always. This property directly violates indistinguishability under chosen-plaintext attack (INDCPA), the minimum security definition for any modern encryption scheme. An adversary who can request encryptions of chosen messages can trivially distinguish between ciphertexts by checking for block equality.

Consider a concrete scenario. A medical records system encrypts patient data field-by-field using AES-128-ECB. The "diagnosis" field is padded to exactly 16 bytes. Every patient diagnosed with "Type 2 Diabetes" produces the same ciphertext block for that field. An attacker with access to the encrypted database and knowledge of one patient's diagnosis can identify every other patient with the same condition — without breaking AES itself. This is an example of how a developer might design an encryption system using AES-128-ECB.

from Crypto.Cipher import AES

key = b"YELLOW SUBMARINE"
cipher = AES.new(key, AES.MODE_ECB)

# Two patient records, same diagnosis field (16 bytes each)
ct1 = cipher.encrypt(b"Type 2 Diabetes ")
ct2 = cipher.encrypt(b"Type 2 Diabetes ")

assert ct1 == ct2 # identical plaintexts will result in identical
ciphertexts

Any system where attacker-controlled input and a secret occupy the same encryption scope is vulnerable to byte-at-a-time recovery. The attacker shifts the alignment so that exactly one unknown byte of the secret falls at the end of a block, then brute-forces that byte by comparing ciphertext blocks against a reference.

# Oracle the attacker can query: returns AES-ECB(prefix || SECRET)
def oracle(prefix): ...

# Goal: recover the first byte of SECRET.
# Trick: send 15 A's so SECRET[0] lands at position 15 of block 0.
target = oracle(b"A" * 15)[:16]

for guess in range(256):  
  if oracle(b"A" * 15 + bytes([guess]))[:16] == target:    
    print("First byte:", bytes([guess]))    
    break

In this example, the attacker tries to perform byte-at-a-time secret recovery. It works because the server encrypts the attacker's input concatenated with a secret. The attacker sends fifteen A's, which forces the server to build a block containing those fifteen A's followed by the unknown first byte of the secret.

They save the resulting ciphertext block as a target. Then they send a second request: fifteen A's plus a guess byte of their choosing. If the first ciphertext block matches the target, the guess equals the secret's first byte — at most 256 attempts. To recover the next byte, the attacker sends fourteen A's instead, so the block ends in the known first byte followed by the unknown second byte, and the procedure repeats. Each round peels off one byte. AES itself is never broken; ECB simply leaks the one bit of information the attack needs, which is whether two plaintexts are equal.

IV Reuse Attacks

CBC mode. In CBC, each plaintext block is XORed with the previous ciphertext block before encryption: Ci = EK(Pi ⊕ Ci−1), with C0 = IV. If two messages share the same IV and key, their first ciphertext blocks are identical whenever their first plaintext blocks are identical. More critically, an attacker who observes that C1 = C′1 knows that P1 = P′1 — a direct information leak.

CTR mode. Counter mode turns AES into a stream cipher. The keystream is generated by encrypting successive counter values: KSi = EK(nonce∥counteri). The ciphertext is Ci = Pi ⊕ KSi . If two messages M and M′ are encrypted with the same nonce:

The keystream cancels entirely. The attacker now holds M ⊕ M′, reducing the problem to the classical two-time pad. If any portion of either plaintext is known or guessable (HTTP headers, JSON structure, email signatures), the corresponding portion of the other plaintext is immediately recovered. From there, crib-dragging where sliding a known word across the XOR output can unravel the rest. Here is an example of how developer would setup an IV reuse in AES-CTR mode.

from Crypto.Cipher import AES

def encrypt(msg, nonce):  
  return AES.new(b"YELLOW SUBMARINE", AES.MODE_CTR,

nonce=nonce).encrypt(msg)

nonce = b"" * 8 # the bug: same nonce used twice

c1 = encrypt(b"Transfer $100 to Alice", nonce)
c2 = encrypt(b"Transfer $999 to Eve!!", nonce)

If an attacker has possession of one plaintext and two or more ciphertexts, he can try to decipher all the other messages encrypted under the same nonce. The reason is that XOR is its own inverse, when given any two ciphertexts produced from the same keystream, XORing them together cancels the keystream and yields the XOR of the two underlying plaintexts. This is an example of how an attacker can achieve this attack.

xor = lambda a, b: bytes(x ^ y for x, y in zip(a, b))

# Attacker knows c1, c2, and guesses m1 (e.g. from a leaked log)
m1 = b"Transfer $100 to Alice"
m2 = xor(xor(c1, c2), m1)

print(m2) # b"Transfer $999 to Eve!!"

Once the attacker knows even one plaintext, every other ciphertext encrypted with that nonce falls in a single XOR operation. One leaked message compromises all of them.

In AES-GCM (Galois/Counter Mode), nonce reuse is even more catastrophic. Beyond exposing plaintext XORs, it reveals the authentication key H = EK(0128), allowing the attacker to forge valid ciphertexts for arbitrary messages. Authentication and confidentiality both fail simultaneously.

Padding Oracle Attack (CBC)

PKCS#7 padding works as follows: if the last block needs n bytes of padding (1 ≤ n ≤ 16), each padding byte is set to the value n. A full block of padding (sixteen bytes of 0x10 ) is appended when the plaintext is already block-aligned. On decryption, the receiver checks that the last byte indicates a valid padding length and that all padding bytes match.

In CBC decryption, the plaintext for block i is computed as:

The attacker targets the last byte of block Pi by modifying the last byte of Ci−1. Let the intermediate decrypted value be I = DK(Ci). The attacker sends the pair (C′i−1, Ci) to the server, where C′i−1 is Ci−1 with the last byte replaced by a guess value g. The server decrypts and gets P′i [15] = I[15] ⊕ g.

The attacker iterates g from 0x00 to 0xFF . When the server reports valid padding, the attacker knows P′i [15] = 0x01 (the simplest valid pad). Therefore I[15] = g ⊕ 0x01. With I[15] known, the real plaintext byte is recovered: Pi[15] = I[15] ⊕ Ci−1[15]. Consider this code snippet to understand how an attacker might achieve the attack.

# Attacker has C_{i-1} and C_i, plus an oracle: oracle(ct) → True if padding
valid
def oracle(ct): ...

# Forge a modified C'_{i-1} and try every value for its last byte
forged = bytearray(C_prev)
for g in range(256):  
  forged[15] = g  
  if oracle(bytes(forged) + C_i):    
    # Server accepted padding → P'_i[15] = 0x01    
    I_15 = g ^ 0x01 # intermediate byte    
    P_15 = I_15 ^ C_prev[15] # real plaintext byte    
    print("Recovered byte:", bytes([P_15])) .  
    break

To recover the second-to-last byte, the attacker sets the last byte of C′i−1 to I[15] ⊕ 0x02 (forcing valid 0x02 padding in the last position) and iterates the second-to-last byte until the server accepts 0x02 0x02 as valid padding. The process continues right to left, recovering each byte with at most 256 oracle queries. A full 16-byte block requires at most 4,096 queries; a typical multi-block message, tens of thousands — entirely feasible over a network.

Real-World Vulnerabilities and CVEs

Padding Oracle: ASP.NET (CVE-2010-3332)

In 2010, security researchers Juliano Rizzo and Thai Duong demonstrated a devastating padding oracle attack against Microsoft's ASP.NET framework. The framework encrypted view state data and authentication tickets using AES-CBC, and the error handling code returned distinctly different responses for padding errors versus application-level errors. An attacker could intercept an encrypted cookie, submit thousands of modified versions to the server, and decode the plaintext from the server's error responses alone. Microsoft issued an emergency out-of-band patch — a rarity that underscored the severity.

Padding Oracle: Lucky Thirteen (CVE-2013-0169)

Lucky Thirteen, published by AlFardan and Paterson in 2013, demonstrated that the TLS record protocol's MAC-then-encrypt construction in CBC mode leaked timing information during padding verification. Even when implementations tried to process valid and invalid padding in constant time, the additional hash compression calls required for different padding lengths created measurable timing differences — on the order of microseconds, but exploitable over thousands of observations. The attack affected OpenSSL, GnuTLS, NSS, and virtually every TLS library shipping CBC cipher suites. Though exploitation required significant network access and measurement precision, it prompted a broad industry migration toward AES-GCM cipher suites in TLS 1.2 and the eventual deprecation of CBC-mode suites in TLS 1.3.

ECB Misuse: Adobe Password Breach (2013)

When Adobe suffered a massive data breach in 2013, investigators discovered that approximately 153 million user passwords had been encrypted — not hashed — using 3DESECB (a block cipher in ECB mode, exhibiting the same deterministic weakness as AES-ECB). Because ECB maps identical plaintexts to identical ciphertexts, the most common encrypted password values were immediately identifiable. Cross-referencing with the plaintext password hints stored alongside them made mass decryption trivial. The breach became a canonical example of why ECB mode must never be used for data that contains patterns or repetition — which is to say, virtually all real-world data.

Nonce Reuse: WPA2 KRACK Attack (CVE-2017-13077 through CVE2017-13088)

The Key Reinstallation Attack (KRACK), published by Mathy Vanhoef in 2017, exploited the WPA2 four-way handshake to force nonce reuse in AES-CCMP, the encryption protocol protecting virtually all modern Wi-Fi traffic. By manipulating and replaying handshake messages, an attacker could cause the client to reinstall an already-in-use encryption key with a reset nonce counter. The result: keystream reuse, enabling decryption and, on Linux and Android clients using wpa_supplicant 2.4+, even packet injection (because the key was reinstalled as an all-zero key). The attack did not break AES or CCMP. It broke the protocol's assumption that nonces would never repeat.

Conclusion

After two decades of public scrutiny, AES remains unbroken as a mathematical construction — the best known attack reduces AES-128 security from 2128 to 2126.1 operations, and even Grover's quantum speedup leaves AES-256 at a comfortable 128-bit post-quantum margin. Yet none of the vulnerabilities catalogued in this article actually attack AES, they attack the decisions surrounding it. ECB preserves patterns by design, nonce reuse collapses stream ciphers into solvable systems, padding oracles turn a single bit of side-channel leakage into full plaintext recovery, and KRACK broke not AES-CCMP but the protocol that fed nonces into it. In every case the algorithm performed exactly as specified; the system failed because the algorithm was asked to operate outside its threat model. The defensive lessons are not subtle, use authenticated encryption (AES-GCM, ChaCha20-Poly1305), never reuse a nonce, abandon ECB, rely on vetted libraries rather than rolling your own, and treat key management as the layer most likely to fail.

Cryptography is easy to deploy and remarkably easy to deploy wrong. AES gives you an unbreakable lock. Whether the door holds depends entirely on how you install it.