AES-GCM: Authenticated Encryption

Introduction

Plain AES encryption only guarantees confidentiality — that an eavesdropper can’t read your data. It says nothing about integrity — whether an attacker silently altered the ciphertext in transit. AES-GCM (Galois/Counter Mode) solves both problems in a single, efficient pass: it encrypts your data using AES in Counter (CTR) mode, and simultaneously computes a cryptographic authentication tag using a specialized hash function called GHASH, built on Galois field (finite field) arithmetic. The combination — encryption plus built-in tamper detection — is called AEAD: Authenticated Encryption with Associated Data, and it’s the default choice for TLS 1.2/1.3, IPsec, SSH, and disk encryption throughout the industry.

Table of Contents

• Why Encryption Alone Isn’t Enough
• Counter (CTR) Mode: The Encryption Half
• GHASH: The Authentication Half
• Associated Data (AAD)
• A Verified Example
• Security Considerations
• Real-World Applications
• FAQ
• References

Why Encryption Alone Isn’t Enough

Consider plain AES-CBC without any separate integrity check: an attacker who can’t read your encrypted traffic can still often flip specific bits of the ciphertext in predictable, exploitable ways, causing the decrypted plaintext to change in a controlled fashion — without ever needing the key. Several real, practical TLS attacks (like the BEAST and Lucky 13 attacks against CBC mode) exploited exactly this class of weakness. AEAD modes close this gap entirely: any tampering with the ciphertext, even a single flipped bit, causes authentication to fail and the entire message to be rejected before decryption is ever trusted.

Counter (CTR) Mode: The Encryption Half

GCM’s encryption step uses AES in Counter mode: rather than encrypting the plaintext directly, AES encrypts a sequence of counter values (derived from a nonce plus an incrementing counter), and the resulting keystream is simply XORed with the plaintext — turning the AES block cipher into a stream cipher, structurally similar in spirit to how ChaCha20 works, just built from AES rather than the ChaCha quarter-round function. Counter mode is fully parallelizable, requires no padding, and lets you decrypt or even randomly access any block independently.

GHASH: The Authentication Half

GHASH computes the authentication tag by processing the associated data and ciphertext through repeated multiplication in GF(2¹²⁸) — a Galois field of 2¹²⁸ elements, using the specific reduction polynomial GCM defines. Each 128-bit block of input is XORed into a running accumulator, which is then multiplied by a secret hash subkey H (itself just AES encrypting an all-zero block under the session key). This construction is fast in hardware (modern CPUs include dedicated PCLMULQDQ instructions specifically to accelerate this Galois field multiplication) and provides a cryptographically strong authentication tag from relatively simple, well-understood finite-field math.

Interactive Visualizer

The visualizer above runs genuine AES-GCM — real AES encryption for the CTR-mode keystream, real GF(2¹²⁸) GHASH multiplication for the authentication tag — and was verified against Node.js’s own built-in AES-GCM implementation (including with associated data) before being published here. Try tampering with the ciphertext after encrypting to see authentication correctly fail.

Associated Data (AAD)

GCM supports authenticating data that isn’t actually encrypted — Associated Data (AAD). This is essential for real protocols: a TLS record’s header (sequence number, length, record type) needs to be protected from tampering, but doesn’t need to be secret, since it’s sent in the clear anyway. GCM folds the AAD into the same GHASH computation as the ciphertext, so any tampering with either the AAD or the ciphertext is caught by the same single authentication tag.

A Verified Example

Using one of the most widely cited NIST GCM test vectors:

• Key: 16 zero bytes
• IV: 12 zero bytes
• Plaintext: 16 zero bytes
• Ciphertext: 0388dace60b6a392f328c2b971b2fe78
• Authentication tag: ab6e47d42cec13bdf53a67b21257bddf (16 bytes)

Every correct AES-GCM implementation, including the one running in the visualizer above, must reproduce this exact ciphertext and tag from these inputs.

Security Considerations

• Never reuse a nonce with the same key. This is GCM’s single most important operational rule — nonce reuse doesn’t just weaken confidentiality, it can let an attacker recover the authentication key entirely, breaking integrity protection for every message ever sent under that (key, nonce) pair. Most protocols either use a securely random 96-bit nonce or a carefully managed counter that’s guaranteed never to repeat.
• Always check the tag before trusting the plaintext. Decrypting first and checking authentication after (rather than verifying, then decrypting) opens the door to padding-oracle-style timing attacks.
• Short tags are dangerous. GCM supports truncated tags, but shortening below the standard 128 bits meaningfully increases forgery risk and should be avoided outside very specific, well-analyzed constraints.

Real-World Applications

• TLS 1.2 and 1.3: AES-GCM is one of the two mandatory AEAD cipher suites in TLS 1.3 (the other being ChaCha20-Poly1305), protecting the vast majority of HTTPS traffic today.
• IPsec: widely used to authenticate and encrypt VPN tunnel traffic.
• Disk encryption: several full-disk and file encryption systems use AES-GCM (or closely related AEAD constructions) to detect tampering with stored ciphertext, not just hide its contents.
• SSH: supported as one of several authenticated encryption cipher options in modern SSH implementations.

FAQ

What does “GCM” stand for?

Galois/Counter Mode — “Galois” refers to the GF(2¹²⁸) Galois field arithmetic used for authentication (GHASH), and “Counter” refers to the CTR-mode encryption.

Is AES-GCM better than AES-CBC?

For nearly all new systems, yes — GCM provides authentication (tamper detection) that plain CBC lacks entirely, closing off an entire class of real-world attacks (like BEAST and Lucky 13) that have historically plagued CBC-based TLS implementations.

What happens if a nonce is reused with AES-GCM?

It’s catastrophic — beyond weakening confidentiality (as with any CTR-mode cipher), nonce reuse can let an attacker recover GCM’s internal authentication key entirely, allowing them to forge valid authentication tags for arbitrary messages going forward.

What’s the difference between AES-GCM and ChaCha20-Poly1305?

Both are AEAD constructions offering equivalent security guarantees. AES-GCM benefits enormously from hardware acceleration (AES-NI and PCLMULQDQ) on modern CPUs, while ChaCha20-Poly1305 performs better in pure software on devices lacking that hardware — which is why TLS 1.3 supports both and negotiates based on what each side can accelerate.

Can GCM encrypt data without also authenticating it?

Not really — GCM is designed as a unified encrypt-and-authenticate operation. If you only need authentication without encryption, GCM supports AAD-only operation (authenticating data that stays in plaintext), but there’s no supported “GCM encryption with authentication disabled” mode, by design.

References

1. NIST SP 800-38D. “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.” Available at: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf

2. McGrew, D. and Viega, J. “The Galois/Counter Mode of Operation (GCM).” — the original GCM design paper, including the widely-used reference test vectors.

3. Wikipedia. “Galois/Counter Mode.” Available at: https://en.wikipedia.org/wiki/Galois/Counter_Mode

4. RFC 5116. “An Interface and Algorithms for Authenticated Encryption.” IETF, 2008 — defines the general AEAD interface GCM implements.