Media Den

Galois/Counter Mode: Why Encryption Alone Is Not Enough

May 2026 · Privacy Advancements Series

Encryption protects data from being read. It does not protect data from being changed. If an attacker modifies encrypted data and the scheme provides no integrity check, the recipient decrypts the altered data without knowing.

In our previous post on AES-256-GCM, we introduced Galois/Counter Mode (GCM) and authenticated encryption. Here, we go deeper: what attacks on unauthenticated encryption looked like, how GCM works, and what discipline it requires.

When Tampering Beats Encryption

The standard defense against tampering is an authentication tag: a short value computed from the ciphertext and a secret key. The sender attaches the tag to the encrypted data; the recipient recomputes it and checks that the two match. If anyone modifies the ciphertext, the tag won't verify, and the data is rejected before decryption. Without a tag, there is no check. Modified ciphertext decrypts silently into modified plaintext.

A block cipher like the Advanced Encryption Standard (AES) encrypts data in fixed-size chunks (128-bit blocks, regardless of key size). A mode of operation defines how to use that cipher to encrypt messages longer than one block: how blocks are chained, how the key and a nonce are applied, and what structure the output has. Standard modes - Electronic Codebook (ECB), Cipher Block Chaining (CBC), Counter (CTR), and others - provide confidentiality only. None include an authentication tag.

Counter mode, for example, XORs a keystream with plaintext, so flipping a bit in the ciphertext flips the corresponding bit in the decrypted output. An attacker who knows the data's structure can change specific values without the key.

CBC had a different weakness. In 2002, Serge Vaudenay showed that if a server reveals whether CBC padding is valid, even indirectly, an attacker can recover the plaintext one byte at a time without the key.^[2] This attack proved durable: Google's POODLE (2014) exploited it in SSL 3.0, and a 2010 ASP.NET vulnerability allowed attackers to forge authentication tokens.^[3] In each case, the encryption was not broken. The problem was that modified ciphertext leaked information through the system's response.

Counter Mode

GCM's encryption component is Counter mode. CTR encrypts a series of counter values (a nonce concatenated with a sequential counter) with AES, then XORs the outputs with the plaintext. Each block can be processed independently, making CTR parallelizable and fast on modern hardware.

But CTR provides only confidentiality. The bit-flipping attack above applies directly: modifying a ciphertext byte changes the corresponding plaintext byte, and nothing detects the alteration.

GHASH and the Galois Field

GCM adds integrity through Galois Hash (GHASH), a hash function that produces the authentication tag. The idea: derive a secret value from the encryption key, then use it to mix every piece of data (the ciphertext, any unencrypted headers, and their lengths) into a single short fingerprint. If one bit of input changes, the fingerprint will be different.

GHASH processes data one block at a time. Each block is combined with the running result, then multiplied by the secret value. Think of a chain where each link is forged from the link before it: by the time you reach the end, the final link depends on every block that came before. After the last block, the result is combined with one more encrypted value to produce the tag. This last step ensures that even the tag itself cannot be forged without the key.

On decryption, the recipient recomputes the tag from the same inputs using the same key and compares it to the tag it received. If they differ, something was modified in transit, and the data is rejected before decryption.

Two Problems, One Pass

Before Authenticated Encryption with Associated Data (AEAD), systems composed encryption and a message authentication code (MAC) separately. The order mattered: the Secure Sockets Layer (SSL) MAC-then-encrypt approach required decrypting before verifying integrity, which is what enabled padding oracle attacks.^[2] The Internet Protocol Security (IPsec) encrypt-then-MAC approach verified before decrypting, and was provably secure.^[4][5] Getting the order wrong broke security silently.

GCM eliminates this choice. Encryption and authentication happen in a single pass: CTR encrypts while GHASH authenticates, sharing the same key and nonce. McGrew and Viega proposed GCM in 2004;^[6] the National Institute of Standards and Technology (NIST) standardized it in 2007;^[1] Transport Layer Security (TLS) 1.3 made AEAD mandatory in 2018.^[8]

What Can Go Wrong

GCM has one critical rule: never reuse a nonce with the same key. A nonce (number used once) is a value attached to each encryption operation to ensure the output is unique. If the same nonce and key are used twice, an attacker can recover enough information to forge messages that pass authentication. Both confidentiality and integrity break at once. In 2016, researchers found 184 HTTPS servers on the public internet reusing GCM nonces in their TLS connections, meaning an attacker could have forged traffic that passed authentication.^[7]

Nonces can be generated randomly or with a counter. Random generation is simpler but becomes risky at high volume: GCM's 96-bit nonce space means collisions grow likely well before you exhaust the space.^[1] Counter-based generation avoids this but requires tracking state across encryptions.