AES BadPaddingException — Why Java 8u161 Broke Decryption

AES became the global encryption standard in 2001 after NIST's public competition. The winner — Rijndael — beat 14 other submissions on security, efficiency, and simplicity. Today it's in every TLS connection, every AES-NI-accelerated processor, and every encrypted storage device.

But here's what most explanations miss: AES itself is mathematically secure. Your production failures won't come from breaking AES-256. They'll come from using ECB mode on structured data, leaking patterns. Or from CBC padding oracle attacks that decrypt data without the key. Or from reusing nonces in GCM mode, which completely breaks authentication.

Understanding AES means knowing what actually breaks in production. The cipher's strength is irrelevant if you're using it wrong.

AES Structure — The Four Operations

AES operates on a 4×4 byte state matrix (128 bits). Each round applies four operations:

SubBytes: Non-linear substitution via an S-box lookup. Each byte independently mapped to another. Provides confusion — hides the key.

ShiftRows: Rotate each row of the state by a different offset. Row 0: no shift. Row 1: shift left 1. Row 2: shift left 2. Row 3: shift left 3. Provides diffusion across columns.

MixColumns: Multiply each column by a fixed matrix in GF(2^8). Ensures each byte affects every other byte in its column. Provides full diffusion.

AddRoundKey: XOR the state with the round key derived from the original key via key schedule. This is where the key is mixed in.

The final round omits MixColumns.

That's the textbook version. Here's what actually matters in production: SubBytes is your only non-linear operation. That's the one that breaks linear cryptanalysis cold. If SubBytes were linear, you could solve for the key with a handful of plaintext-ciphertext pairs. That's why the S-box is so carefully designed—it's the cryptographic heart of AES.

ShiftRows and MixColumns work together to spread a single changed plaintext byte across the entire ciphertext block. Change one bit in your input, and after a few rounds every output bit has a 50% chance of flipping. That's the avalanche effect you need. Without it, patterns in your plaintext leak straight through.

AddRoundKey seems simple—just XOR. But the key schedule is where side-channel attacks live. Generating those round keys leaks timing information if you're not careful. Most AES implementations don't fail in the core rounds—they fail in key expansion.

Using AES Correctly in Python

Python's cryptography library is the standard. Don't roll your own AES implementation. Ever.

You'll use Fernet for most cases — it's a batteries-included wrapper around AES-128 in CBC mode with HMAC authentication. It handles IV generation, padding, and authentication for you.

For more control, use AESGCM directly. That's AES in Galois/Counter Mode, which gives you authenticated encryption without separate HMAC steps. It's faster and simpler than CBC+HMAC, but you must manage nonces correctly.

Here's the problem: most tutorials show you AES in ECB mode. That's broken — identical plaintext blocks produce identical ciphertext blocks. Never use ECB for anything but education.

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# AES-GCM: authenticated encryption — the correct choice for most applications
def aes_gcm_encrypt(key: bytes, plaintext: bytes, aad: bytes = b'') -> tuple[bytes, bytes]:
    """Encrypt with AES-GCM. Returns (nonce, ciphertext+tag)."""
    nonce = os.urandom(12)  # 96-bit nonce — NEVER reuse with same key
    aesgcm = AESGCM(key)
    ciphertext = aesgcm.encrypt(nonce, plaintext, aad)
    return nonce, ciphertext

def aes_gcm_decrypt(key: bytes, nonce: bytes, ciphertext: bytes, aad: bytes = b'') -> bytes:
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(nonce, ciphertext, aad)

# Generate a 256-bit key
key = os.urandom(32)
nonce, ct = aes_gcm_encrypt(key, b'Hello, secure world!', aad=b'additional data')
pt = aes_gcm_decrypt(key, nonce, ct, aad=b'additional data')
print(f'Decrypted: {pt}')

Cipher Modes — Why ECB is Broken

AES encrypts exactly 128 bits at a time. For longer messages, you need a mode of operation to chain blocks together. That's where most engineers get it wrong — picking the wrong mode breaks your encryption completely.

ECB (Electronic Codebook): Each block encrypted independently with the same key. Never use it. Identical plaintext blocks produce identical ciphertext blocks, leaking pattern information. The famous ECB penguin image shows this: encrypt a bitmap with ECB and you can still see the penguin's outline in the ciphertext. That's why ECB is broken — it's deterministic.

CBC (Cipher Block Chaining): Each block XORed with previous ciphertext before encryption. Better than ECB, but requires padding and is vulnerable to padding oracle attacks if not authenticated. CBC's sequential nature also kills parallel encryption performance. You'll see this when encrypting large files — it's slow.

GCM (Galois/Counter Mode): Stream mode plus authentication tag. Provides both confidentiality and integrity in one operation. The standard for new code — authenticated encryption (AEAD). Use this unless you've got a specific reason not to. GCM's counter mode also means you can parallelize encryption, which matters at scale.

Here's the thing: most libraries default to ECB or CBC for backward compatibility. You have to explicitly choose GCM. If you don't, you're running broken crypto by default.

AES-NI Hardware Acceleration

Modern x86 processors (Intel since 2010, AMD since 2011) include AES-NI hardware instructions. They perform a full AES round in a single CPU instruction. That's why AES-128-GCM often beats SHA-256 on modern hardware.

Python's cryptography library taps into AES-NI automatically through OpenSSL. AES-256-GCM hits >1GB/s throughput on a single core. That's the real reason AES stays the default — when hardware acceleration exists, AES wins on speed.

But here's what most explanations miss: AES-NI isn't guaranteed. Your code might run on ARM, older cloud instances, or virtualized environments where it's disabled. You can't just assume it's there.

Frequently Asked Questions