Skip to main content
Commerce Security Authority
Category: Cryptography Fundamentals

Galois/Counter Mode

Also known as: GCM, AES-GCM
Simply put

Galois/Counter Mode (GCM) is a way of using a block cipher, such as AES, that both scrambles data to keep it confidential and generates a tag to confirm the data has not been tampered with. Because it works on independent blocks, it can process data in parallel, which can make it fast. It is commonly used in secure communications protocols such as TLS.

Formal definition

GCM is a block cipher mode of operation that provides authenticated encryption with associated data (AEAD), delivering both confidentiality and authenticity/integrity for encrypted data as well as authenticity for additional associated (non-encrypted) data. As specified by NIST in SP 800-38D, GCM combines counter (CTR) mode encryption with a universal hash function computed over a binary Galois field to produce an authentication tag. Because it operates as a counter mode, its blocks are independent, allowing encryption and decryption to be parallelized, in contrast to sequential modes such as cipher block chaining (CBC). GCM is defined for use with AES in TLS cipher suites (for example, per RFC 5288, with RSA, DSA, and Diffie-Hellman-based key exchange). GMAC is the authentication-only variant of the same construction.

Why it matters

GCM matters because it provides authenticated encryption with associated data (AEAD), meaning it addresses both confidentiality and integrity in a single construction rather than requiring separate mechanisms bolted together. This combination helps reduce the risk of certain implementation errors that can arise when encryption and message authentication are handled independently. For teams protecting cardholder data in transit, AEAD modes such as AES-GCM are among the constructions used in modern TLS cipher suites, as defined in RFC 5288 for use with RSA, DSA, and Diffie-Hellman-based key exchange.

Beyond the security properties, GCM's design has practical performance implications. Because it operates as a counter mode, its blocks are independent, which allows encryption and decryption to be parallelized, in contrast to sequential modes such as cipher block chaining (CBC). This can make it well suited to high-throughput environments where large volumes of encrypted traffic must be processed efficiently.

It is important to recognize what GCM does and does not address. GCM is a cryptographic mode of operation specified by NIST in SP 800-38D; it is not itself a compliance standard, and its correct use depends on implementation choices such as key and nonce management, which fall outside the definition of the mode itself. The strength of any deployment depends on those surrounding controls, not on the label AES-GCM alone. Whether a particular use of encryption reduces PCI DSS scope or satisfies a specific requirement depends on implementation and validation, and readers should confirm applicable controls against the current published standard.

Who it's relevant to

Security engineers
Engineers configuring TLS and other secure communication channels encounter AES-GCM as an AEAD cipher suite option, for example those defined in RFC 5288. Understanding that GCM provides both confidentiality and integrity in one construction, and that its security depends on correct key and nonce handling, helps inform sound configuration choices.
Cryptography and platform architects
Architects selecting modes of operation weigh GCM's parallelizable, counter-based design against sequential modes such as CBC. They can reference the authoritative specification in NIST SP 800-38D to understand the mode's properties and constraints when designing systems that protect data in transit.
Compliance officers
Those assessing how encryption is applied to cardholder data should note that GCM is a cryptographic mode, not a compliance standard. Whether a given implementation supports scope reduction or satisfies an encryption-related control depends on implementation and validation, and should be confirmed against the current published PCI DSS.

Inside GCM

Authenticated encryption with associated data (AEAD)
GCM is an AEAD mode of operation that combines confidentiality for the plaintext with integrity and authenticity for both the ciphertext and any additional associated data, producing an authentication tag alongside the ciphertext.
Underlying block cipher
GCM operates on top of an approved block cipher, most commonly AES, applied in counter mode for encryption. The security of the construction depends on the strength and correct use of the underlying cipher.
Counter mode (CTR) encryption
The confidentiality component derives a keystream by encrypting successive counter values and XORing the result with the plaintext, meaning identical inputs under the same key and counter would produce identical keystream.
Initialization vector / nonce
GCM requires a nonce (initialization vector) that must be unique per encryption operation under a given key. Reuse of a nonce with the same key can undermine both confidentiality and the integrity guarantees of the mode.
GHASH and the authentication tag
A universal hash function over a Galois field processes the ciphertext and associated data to produce an authentication tag, which a recipient verifies to detect tampering before trusting the decrypted data.
Additional authenticated data (AAD)
Data that is authenticated but not encrypted, such as headers or context that must be bound to the ciphertext, allowing integrity protection without confidentiality for those fields.

Common questions

Answers to the questions practitioners most commonly ask about GCM.

Does GCM by itself make stored cardholder data compliant with PCI DSS?
No. GCM is an authenticated encryption mode that provides confidentiality and integrity for data it protects, but using it does not by itself satisfy PCI DSS. Encryption is only one element of the applicable requirements, which also address key management, key lifecycle, access controls, and validation of the overall implementation. The effect of encryption on scope and compliance depends on how it is implemented, how keys are managed and separated from the data, and how the environment is validated—not on the choice of cipher mode alone. Confirm the specific requirements against the current published PCI DSS, as numbering and wording differ between versions.
Since GCM authenticates the data, does it replace the need for a separate message authentication or signing control?
Not necessarily. GCM provides authenticity and integrity for the ciphertext and any associated data it covers within a single encryption operation using the same key. It is intended to detect tampering of the protected message, but it does not perform the functions of a broader signing scheme, such as non-repudiation between distinct parties or authentication of a message under a separate signing key. Whether GCM's built-in authentication is sufficient depends on the threat model and the design of the overall protocol; it should not be assumed to cover authentication needs it was not designed to address.
What is the most critical implementation pitfall to avoid when using GCM?
Reusing an initialization vector (nonce) with the same key is a well-known and serious failure mode for GCM. Nonce reuse under a single key can undermine both the confidentiality guarantees and the integrity guarantees the mode is intended to provide. Implementations should ensure nonces are unique for every encryption performed with a given key, using an approach appropriate to the environment. This is an implementation-level concern that helps preserve the security properties GCM is designed to offer; it does not, by itself, address other controls such as key management or access restrictions.
How should the authentication tag produced by GCM be handled and verified?
The authentication tag should be stored or transmitted alongside the ciphertext and verified on decryption before any decrypted plaintext is used. If tag verification fails, the implementation should treat the data as untrusted and not act on the decrypted output. Tag length is a configurable parameter, and shorter tags reduce the strength of the integrity check; select a tag length consistent with your organization's cryptographic guidance and applicable standards. Verification behavior is an implementation detail that determines whether GCM's integrity property is actually realized.
Can additional data such as headers be authenticated with GCM without being encrypted?
Yes. GCM supports additional authenticated data (AAD), which is covered by the authentication tag but is not encrypted. This can be used to bind non-secret context—such as headers or metadata—to the ciphertext so that tampering with that context is detectable. The AAD is not kept confidential, so it should not contain data that must remain secret. How AAD is defined and validated is an implementation decision, and it should reflect the specific integrity requirements of the protocol.
Does the choice of GCM change how sensitive authentication data may be handled?
No. The prohibition on storing sensitive authentication data after authorization—such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks—applies regardless of the cipher mode used. Encrypting such data with GCM does not permit its retention after authorization. GCM may be appropriate for protecting cardholder data that is permitted to be stored under defined controls, but the distinction between cardholder data and sensitive authentication data, and the associated storage rules, are independent of the encryption algorithm chosen. Confirm the applicable rules against the current published PCI DSS.

Common misconceptions

Encrypting cardholder data with AES-GCM by itself satisfies PCI DSS storage requirements.
The choice of a strong AEAD mode is only one element. PCI DSS also addresses key management, access controls, scope, and validation, and its effect on scope depends on implementation and validation rather than the cipher label. Confirm applicable requirements against the current published standard. Separately, sensitive authentication data such as full track data, card verification values, and PINs or PIN blocks must not be stored after authorization even when encrypted with GCM.
Because GCM provides authentication, it is a form of tokenization and removes data from scope.
GCM is encryption that transforms data reversibly with a key; it is not tokenization, truncation, masking, or hashing, which reduce or transform data differently. Whether any of these affects PCI DSS scope depends on how it is implemented and validated, not on the technique's name.
GCM nonces can be chosen freely or repeated as long as the key stays secret.
GCM depends on nonce uniqueness per key. Reusing a nonce with the same key can compromise confidentiality and the integrity guarantees the authentication tag is intended to provide, so nonce management is a critical operational control.

Best practices

Ensure every encryption operation under a given key uses a unique nonce, and design nonce generation and tracking so reuse cannot occur across restarts, clustering, or key reuse.
Always verify the authentication tag before acting on or exposing any decrypted plaintext, and treat verification failure as a hard error that discards the data.
Bind relevant context to the ciphertext through additional authenticated data where appropriate, so that fields requiring integrity but not confidentiality are still authenticated.
Manage keys under defined controls, including secure generation, storage, rotation, and destruction, since the strength of GCM depends on protecting the underlying key.
Do not rely on GCM to justify storing sensitive authentication data; such data must not be retained after authorization even when encrypted, and evaluate scope impact through implementation and validation rather than the encryption label.
Confirm the specific applicable PCI DSS requirements and any related standards against the current published versions rather than assuming fixed requirement numbers, since wording and numbering differ between versions.