up:: Classical Cryptography MOC

Galois-Counter Mode (GCM)

Galois/Counter Mode (GCM) is a mode of operation for a block cipher, standardized by NIST in SP 800-38D, that provides both confidentiality and integrity/authentication of data in one pass. It is almost always paired with AES as AES-GCM, and it belongs to the family called authenticated encryption with associated data (AEAD): it encrypts a message, authenticates that ciphertext, and also authenticates extra cleartext data such as packet headers. That combination is why AES-GCM is a required cipher suite in TLS 1.3 and the workhorse behind most encrypted web traffic. The quantum story is reassuring, because GCM is symmetric, so Grover’s algorithm only weakens its key search rather than breaking it, and AES-256-GCM keeps a wide margin. Its one real hazard is classical: reusing a nonce with the same key destroys GCM’s guarantees.

Source: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, csrc.nist.gov/pubs/sp/800/38/d/final.

The short version:

• GCM is an AEAD mode: it gives you confidentiality and integrity/authentication together, so the recipient can both read a message and detect any tampering with it.
• It is a wrapper around a block cipher, almost always AES, which is why you see the string “AES-256-GCM” in modern cipher suites rather than plain AES.
• It authenticates extra cleartext data too (called associated data), so a header or sequence number can be bound to the encrypted payload without being hidden.
• AES-GCM is mandatory in TLS 1.3 and carries the bulk of encrypted internet traffic, largely because it is fast, parallelizable, and hardware-accelerated.
• It survives the quantum transition. GCM is symmetric, so only Grover’s algorithm applies, and that just halves the key-search margin. AES-256-GCM keeps about 128 bits of effective security.
• Its one sharp edge is a classical footgun: reusing the same nonce with the same key breaks both the confidentiality and the authentication, so correct nonce handling is part of using it safely.

Picture a tamper-evident shipping envelope. A plain cipher is a locked box: it hides what’s inside, but it says nothing about whether someone opened it, swapped the contents, or rewrote the shipping label.

GCM is that locked box plus a wax seal stamped across the lid and the label at the same time. If anyone alters the contents or the label in transit, the seal doesn’t match and the recipient throws the whole thing away unread. You get privacy and proof-of-untampered in one motion, which is exactly what a modern secure connection needs.

What is Galois/Counter Mode (GCM)?

Galois/Counter Mode is an authenticated-encryption mode of operation that NIST approved in SP 800-38D for use with any approved 128-bit block cipher, in practice AES. A “mode of operation” is the scaffolding that turns a block cipher, which only transforms one fixed-size block, into something that can protect a message of any length. GCM’s distinguishing feature is that it does two jobs at once:

1. Confidentiality, by running the block cipher in counter mode (CTR) to produce a keystream that encrypts the data.
2. Authentication, by computing a value called an authentication tag over the ciphertext and any associated data, using arithmetic in the Galois field GF(2^128). The tag is what makes tampering detectable.

The name captures both halves: “Counter” for the confidentiality mechanism, “Galois” for the field arithmetic behind the authentication. A tag-only variant that authenticates data without encrypting it is called GMAC, which is just GCM with an empty plaintext. Because GCM authenticates associated data alongside the encrypted payload, it is an AEAD mode, the interface formalized in RFC 5116 and registered there as AEAD_AES_128_GCM and AEAD_AES_256_GCM.

Sources: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, csrc.nist.gov/pubs/sp/800/38/d/final; D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

How does AES-GCM work?

AES-GCM takes four inputs, a key, a nonce (called the initialization vector, or IV), the plaintext, and optional associated data, and produces two outputs, the ciphertext and an authentication tag. Under the hood it runs two coupled machines over the same key:

1. Counter-mode encryption produces the ciphertext. GCM derives a starting counter block from the nonce, then increments a 32-bit counter for each successive block. Each counter value is encrypted with the block cipher to produce a block of keystream, and that keystream is combined with the plaintext by XOR to make the ciphertext. Because each block’s keystream depends only on the key and the counter, the blocks can be computed in parallel.
2. GHASH produces the authentication tag. GCM feeds the associated data and the ciphertext into a keyed hash called GHASH, which accumulates them through repeated multiplication in the Galois field GF(2^128) against a hash subkey derived by encrypting an all-zero block. The GHASH result is then encrypted against the starting counter block to produce the final tag.

The sender transmits the ciphertext, the nonce, and the tag. The receiver recomputes GHASH over the ciphertext and associated data it received, encrypts it the same way, and compares the result against the tag. If they match, the data is authentic and gets decrypted; if a single bit of the ciphertext, the associated data, or the tag was altered, the tags differ and the receiver rejects the whole message. This is the crucial discipline of AEAD: decryption and verification are one operation, so tampered data is never handed to the application.

Two design choices matter for how GCM behaves in the real world. Associated data is authenticated but not encrypted, which is exactly what you want for a network header that must stay readable by routers yet must not be forgeable. And the confidentiality mechanism is stream-cipher-like (CTR mode), which is what makes reusing a nonce so dangerous, a point the note returns to below.

Source: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, §7 (authenticated encryption and decryption), csrc.nist.gov/pubs/sp/800/38/d/final.

What does GCM add over a plain cipher mode?

GCM adds tamper detection and header authentication on top of the confidentiality that a plain mode provides, and it does it in a single pass over the data. A confidentiality-only mode like CBC or CTR hides the contents of a message but proves nothing about whether it arrived unchanged, so it has to be bolted to a separate message authentication code (an encrypt-then-MAC construction) to be safe. GCM folds that second step into the mode itself. The comparison:

Property	Plain confidentiality mode (CBC, CTR)	GCM (AEAD)
Hides message contents (confidentiality)	Yes	Yes
Detects tampering (integrity / authentication)	No, needs a separate MAC	Yes, built in via the authentication tag
Authenticates cleartext associated data (headers)	No	Yes
Passes over the data	One for encryption, plus another for a bolt-on MAC	One combined pass
Parallelizable	CTR yes, CBC no	Yes, both the CTR encryption and GHASH
Main failure mode	MAC omitted or wrongly composed	Nonce reused under the same key

The practical upshot is that GCM removes an entire category of implementation mistake. Composing encryption and authentication by hand is historically where protocols get broken (wrong order, MAC over the wrong bytes, timing leaks in the comparison), and an AEAD mode gives the developer a single primitive that is safe by construction as long as nonces stay unique. That is why standards bodies moved toward AEAD-only designs, and why TLS 1.3 removed the older bolt-on constructions entirely.

Sources: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, csrc.nist.gov/pubs/sp/800/38/d/final; D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

Why does GCM dominate modern TLS?

GCM dominates because TLS 1.3 requires AEAD for every cipher suite, and AES-GCM is the AEAD mode with the deepest hardware support. RFC 8446, the TLS 1.3 specification, makes AES-128-GCM (the cipher suite TLS_AES_128_GCM_SHA256) mandatory to implement, so every conforming TLS 1.3 stack ships it. Three things make it the default rather than merely an option:

1. It is AEAD, which TLS 1.3 mandates. TLS 1.3 dropped all of the older confidentiality-only-plus-separate-MAC constructions and permits only authenticated-encryption modes, so the specification itself rules out a bolt-on MAC design. AES-GCM fits that requirement natively.
2. It is fast and parallelizable. The counter-mode keystream and the GHASH authentication both parallelize, and modern CPUs carry dedicated instructions for the two hot paths (AES round instructions for the cipher, carry-less multiplication for the GF(2^128) arithmetic), so AES-GCM runs at multi-gigabit speeds on commodity hardware.
3. TLS constructs its nonces safely. GCM’s one real hazard is nonce reuse, and TLS 1.3 sidesteps it by building each record’s nonce from a per-connection static value XORed with the record sequence number, guaranteeing a unique nonce per record without the implementer having to get it right by hand.

The important thing to hold is that none of this concerns the quantum transition. The exposed part of a TLS session is the key-exchange step that agrees on the session key, not the AES-GCM that encrypts the traffic afterward. GCM stays exactly as strong through the migration.

Sources: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, §9.1 (mandatory cipher suites) and §5.3 (per-record nonce), rfc-editor.org/rfc/rfc8446.

Is AES-GCM quantum-safe?

Yes. AES-GCM is quantum-safe at 256-bit keys because it is symmetric, so the only quantum attack that applies is Grover’s algorithm, and Grover only speeds up brute-force key search quadratically. That halves the effective key strength rather than breaking the cipher. Walking it through:

1. GCM’s security rests on the strength of its underlying block cipher and the size of its key, not on the factoring or discrete-log math that Shor’s algorithm demolishes. Shor does not apply to AES or to GCM at all.
2. Grover turns roughly 2^n key-search work into roughly 2^(n/2), which halves the bits of security. AES-256-GCM starts at 256 bits and keeps about 128 bits of effective security against a quantum attacker, which is far out of reach.
3. AES-128-GCM drops to about 64 bits of idealized quantum strength under the same attack, which is why the durable symmetric baseline is AES-256, including in GCM mode.

The authentication side is quantum-safe on the same terms. The tag length (up to 128 bits) sets the forgery resistance, and Grover offers no structural shortcut against a correctly used GMAC/GCM tag beyond the generic square-root effect. So the honest headline for GCM matches the one for AES itself: the quantum threat lands on the public-key key exchange that delivers the key, and a strong symmetric mode like AES-256-GCM carries forward through the transition unchanged.

Sources: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final; NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, csrc.nist.gov/pubs/sp/800/38/d/final.

What happens if a GCM nonce is reused?

Reusing the same nonce with the same key breaks GCM completely, which is its single most important operational rule. SP 800-38D states the uniqueness requirement directly: distinct messages encrypted under one key must use distinct IVs, and the security of GCM depends on it. Two things go wrong when a nonce repeats:

1. Confidentiality collapses. GCM encrypts with a counter-mode keystream that depends only on the key and the nonce. Two messages encrypted under the same key and nonce use the same keystream, so combining the two ciphertexts by XOR cancels the keystream and exposes the XOR of the two plaintexts, the classic two-time-pad failure.
2. Authentication collapses. A repeated nonce leaks enough information about the GHASH hash subkey that an attacker can recover it and then forge valid tags for messages of their choosing, defeating the integrity guarantee.

This is why nonce management is part of using GCM correctly, and why well-designed protocols never leave it to chance. TLS 1.3 derives the nonce deterministically from a counter so it cannot repeat within a connection; other systems use a dedicated construction from SP 800-38D or switch to a nonce-misuse-resistant mode where the risk is unacceptable. None of this touches the quantum question. Nonce reuse is a classical implementation hazard, present with or without a quantum computer.

Source: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, §8 (uniqueness requirement on IVs) and Appendix A, csrc.nist.gov/pubs/sp/800/38/d/final.

What are GCM’s parameters and limits?

GCM has a small set of fixed parameters and a couple of hard limits that come straight from SP 800-38D. The nonce has a recommended length, the tag has a set of approved lengths, and a single key can only safely encrypt so much data before its guarantees weaken.

Parameter	Value	Notes
Block size	128 bits	Fixed by the underlying cipher, AES
Key size	128, 192, or 256 bits	AES-256-GCM is the quantum-durable baseline
Recommended nonce (IV) length	96 bits (12 bytes)	The efficient, recommended case; other lengths are hashed first
Authentication tag length	up to 128 bits	128, 120, 112, 104, or 96 bits approved; 64 and 32 only for specific limited uses
Max plaintext per invocation	2^39 − 256 bits (about 64 GiB)	Hard ceiling for one encrypt call under one nonce
Field for authentication	GF(2^128)	The Galois field the GHASH multiplications run in

The tag-length choice is a real security parameter, not a formality: a shorter tag is easier to forge, so SP 800-38D restricts the short 64- and 32-bit tags to applications that explicitly analyze the risk. The per-key data limits exist because GCM’s guarantees degrade as more data is processed under one key, which is one more reason protocols rotate keys and rely on forward secrecy rather than encrypting endlessly under a single key.

Source: NIST, “Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, §5.2.1 (IV lengths), §5.2.1.2 and Appendix C (tag lengths), §5.2.1.1 (input length limits), csrc.nist.gov/pubs/sp/800/38/d/final.

Common misconceptions

1. “AES-GCM is a different cipher from AES.” It is the same cipher, AES, run in a particular mode. GCM is the wrapper that adds authentication and lets AES protect messages of any length.
2. “GCM encrypts the header along with the payload.” Associated data is authenticated but left in the clear on purpose, so a router can read a header while still being unable to forge it. Only the plaintext payload is encrypted.
3. “A quantum computer will break AES-GCM.” It will not. GCM is symmetric, so only Grover’s algorithm applies, and AES-256-GCM keeps about 128 bits of effective security. There is no post-quantum replacement to migrate GCM to.
4. “GCM guarantees security no matter how you use it.” Its guarantees depend on never reusing a nonce with the same key. A repeated nonce breaks both confidentiality and authentication, regardless of key size.
5. “You still need a separate MAC with GCM.” You do not. The authentication tag is the MAC, computed by the mode itself, which is the whole point of an AEAD mode.
6. “The authentication tag proves who sent the message.” It proves the message was not altered and came from someone holding the shared key, which is integrity and authenticity, not non-repudiation. Proving a specific individual signed it is the job of a digital signature.

Questions people ask

Is AES-GCM safe to use today? Yes. AES-GCM is a NIST-approved mode (SP 800-38D), it is mandatory in TLS 1.3, and at 256-bit keys it stays safe against both classical and quantum attackers. Its correct use hinges on unique nonces, which well-built protocols handle automatically.

What is the difference between GCM and GMAC? GMAC is GCM with no plaintext to encrypt: it authenticates data without hiding it, producing just a tag. GCM does both jobs, encrypting a payload and authenticating it plus any associated data.

Does AES-GCM need to be replaced for post-quantum security? No. GCM is symmetric and faces only Grover’s algorithm, which halves the key-search margin. AES-256-GCM keeps about 128 bits of effective security, so it carries forward unchanged while the public-key layer around it gets replaced.

Why is nonce reuse such a big deal in GCM? Because GCM encrypts with a keystream that depends only on the key and nonce, and it derives its authentication subkey the same way. Reusing a nonce under one key exposes the XOR of two plaintexts and lets an attacker recover the authentication subkey to forge tags. Both guarantees fail at once.

What is AEAD, and why does it matter? AEAD stands for authenticated encryption with associated data, an interface (RFC 5116) where one primitive both encrypts a payload and authenticates that payload plus extra cleartext data. It matters because it removes the error-prone step of bolting a separate MAC onto a cipher by hand.

How is AES-GCM different from ChaCha20-Poly1305? Both are AEAD modes that TLS 1.3 supports and that provide the same confidentiality-plus-integrity guarantee. AES-GCM leans on AES hardware acceleration, while ChaCha20-Poly1305 is a software-friendly alternative that runs fast on devices without AES instructions. The security properties are comparable when each is used correctly.

What nonce length should AES-GCM use? 96 bits (12 bytes) is the recommended length in SP 800-38D, because it is the efficient case that GCM uses directly. Other lengths are permitted but get hashed first, and the real requirement is that the nonce never repeats under a given key.

Does GCM provide non-repudiation? No. GCM’s tag proves the data is untampered and came from a holder of the shared key, which is integrity and authenticity. Because the key is shared, either party could have produced the tag, so it cannot prove which one did. That requires a digital signature.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.