Modern Symmetric Encryption: AES-GCM vs AES-CBC and Authenticated Data (AEAD)

1. The Anatomy of AES Block Cipher Modes: Electronic Codebook (ECB) to CBC

AES operates strictly on fixed-size 128-bit (16-byte) blocks of data using key lengths of 128, 192, or 256 bits. Operating on arbitrary data lengths requires a block cipher mode. The naive mode, Electronic Codebook (ECB), encrypts each 16-byte block independently with the same key. Because identical plaintext blocks produce identical ciphertext blocks, ECB leaks underlying data patterns (famously demonstrated by the ECB Penguin outline) and is categorically unsafe.

Cipher Block Chaining (CBC) addresses this by XORing each plaintext block with the preceding ciphertext block prior to encryption. The initial block is XORed with a random Initialization Vector (IV). While CBC obscures plaintext patterns, it provides confidentiality only—it provides zero cryptographic authenticity or integrity.

Because CBC operates on 16-byte blocks, plaintexts whose lengths are not clean multiples of 16 bytes must be padded. The industry standard, PKCS#7 (RFC 5652), appends $N$ bytes, each having value $N$. If the input is already a multiple of 16, an entire 16-byte block of padding (`0x10 * 16`) is appended.

// PKCS#7 Padding Rules for 16-byte AES Blocks:
// 14 bytes input: appends 2 bytes of 0x02  -> [ ... 0x02, 0x02 ]
// 15 bytes input: appends 1 byte of 0x01   -> [ ... 0x01 ]
// 16 bytes input: appends 16 bytes of 0x10 -> [ ... 0x10, 0x10, ... 0x10 ]

2. The Padding Oracle Catastrophe in AES-CBC

Because CBC does not authenticate ciphertext, an adversary capable of intercepting ciphertexts can tamper with arbitrary bytes. In 2002, cryptographer Serge Vaudenay demonstrated that if an application distinguishes between a decryption failure caused by 'invalid padding' versus 'invalid data' (through distinct HTTP error codes, error messages, or millisecond timing differentials), an attacker can systematically decrypt the entire ciphertext without possessing the key.

By sequentially modifying the second-to-last ciphertext block byte-by-byte and querying the server oracle, the attacker determines precisely which byte values satisfy PKCS#7 padding invariants. Solving this byte-by-byte enables complete recovery of any 128-bit plaintext block within an average of only 128 to 256 queries per byte ($256 \times 16 = 4096$ requests per block).

Historically, high-profile exploits including the POODLE attack against SSLv3/TLS, Lucky Thirteen against TLS CBC suites, and ASP.NET ViewState decryptions were direct manifestations of CBC padding oracle vulnerabilities. Mitigating this with encrypt-then-MAC (HMAC-SHA256) requires delicate constant-time code that is notoriously prone to implementation flaws.

3. Galois/Counter Mode (AES-GCM): Authenticated Encryption (AEAD)

AES-GCM (NIST SP 800-38D) fundamentally solves malleability and padding oracle hazards by combining Counter (CTR) mode encryption with universal hashing over a Galois field ($GF(2^{128})$) to compute an authentication tag (typically 128 bits). GCM is an Authenticated Encryption with Associated Data (AEAD) scheme.

CTR mode turns the block cipher into a stream cipher: AES encrypts a sequence of incrementing counter blocks, which are XORed with the plaintext. Consequently, GCM requires zero padding; plaintexts of arbitrary byte lengths can be encrypted without single-byte overhead.

Crucially, the recipient verifies the GMAC authentication tag prior to decrypting or exposing any plaintext. If even a single bit of the ciphertext or Initialization Vector has been tampered with in transit, authentication fails immediately, and the decryption algorithm aborts without leaking any information.

// Modern Browser Web Crypto API AES-GCM Implementation:
async function encryptAesGcm(plaintext: Uint8Array, key: CryptoKey): Promise<{ ciphertext: ArrayBuffer; iv: Uint8Array }> {
  // NIST SP 800-38D strongly recommends a 12-byte (96-bit) IV for GCM
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    {
      name: "AES-GCM",
      iv: iv,
      tagLength: 128 // 128-bit authentication tag appended automatically
    },
    key,
    plaintext
  );
  return { ciphertext, iv };
}

4. The Fatal Danger of GCM Nonce (IV) Reuse

While AES-GCM offers gold-standard cryptographic security, it possesses one fatal fragility: Nonce / IV Reuse. In GCM, the IV functions as a nonce (number used once). If the same key and the same 96-bit IV are ever used to encrypt two distinct messages, the entire security foundation of GCM disintegrates.

First, because CTR mode XORs plaintext with keystream ($C_1 = P_1 \oplus K$, $C_2 = P_2 \oplus K$), an attacker XORing the two ciphertexts ($C_1 \oplus C_2$) eliminates the keystream, exposing the raw XOR of the plaintexts ($P_1 \oplus P_2$), trivially solvable using frequency analysis.

Second, and more catastrophically, reusing an IV allows an adversary to solve the polynomial GMAC equations to extract the internal authentication hash key ($H$). Once $H$ is recovered, the attacker can forge valid authentication tags for arbitrary forged messages under that encryption key.

Engineers must either generate cryptographically random 96-bit nonces using `crypto.getRandomValues()` (re-keying well before $2^{32}$ encryptions to avoid birthday paradox collisions) or utilize deterministic 96-bit sequence counters.

5. Safe Client-Side Cryptographic Tooling and Web Crypto Primitives

When encrypting configuration files, credentials, or personal notes in web utilities, developers must never implement custom AES rounds or rely on obsolete pure-JS crypto libraries susceptible to cache-timing side-channel attacks. The W3C Web Cryptography API (`window.crypto.subtle`) interfaces directly with native operating system and hardware-accelerated CPU instructions (such as Intel AES-NI and ARMv8 Cryptography Extensions).

Running cryptographic utilities strictly client-side ensures that plaintext keys, passphrases derived via PBKDF2/Argon2, and decrypted artifacts never cross external network connections, preserving absolute user confidentiality.

Summary & Best Practices

AES-CBC lacks message integrity and suffers from fatal padding oracle vulnerabilities unless paired with constant-time HMAC. AES-GCM is the modern AEAD standard providing high-speed authenticated encryption, zero padding requirements, and tamper detection—provided the 96-bit IV is never reused under the same key.