Hubbry Logo
Galois/Counter ModeGalois/Counter ModeMain
Open search
Galois/Counter Mode
Community hub
Galois/Counter Mode
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Galois/Counter Mode
Galois/Counter Mode
Galois/Counter Mode
View on Wikipedia
from Wikipedia

In cryptography, Galois/Counter Mode (GCM)[1] is a mode of operation for symmetric-key cryptographic block ciphers which is widely adopted for its performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with inexpensive hardware resources.[2]

The GCM algorithm provides data authenticity, integrity and confidentiality and belongs to the class of authenticated encryption with associated data (AEAD) methods. This means that as input it takes a key K, some plaintext P, and some associated data AD; it then encrypts the plaintext using the key to produce ciphertext C, and computes an authentication tag T from the ciphertext and the associated data (which remains unencrypted). A recipient with knowledge of K, upon reception of AD, C and T, can decrypt the ciphertext to recover the plaintext P and can check the tag T to ensure that neither ciphertext nor associated data were tampered with.

GCM uses a block cipher with block size 128 bits (commonly AES-128) operated in counter mode for encryption, and uses arithmetic in the Galois field GF(2128) to compute the authentication tag; hence the name.

Galois Message Authentication Code (GMAC) is an authentication-only variant of the GCM which can form an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length.

Different block cipher modes of operation can have significantly different performance and efficiency characteristics, even when used with the same block cipher. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an instruction pipeline or a hardware pipeline. By contrast, the cipher block chaining (CBC) mode of operation incurs pipeline stalls that hamper its efficiency and performance.

Basic operation

[edit]

Like in normal counter mode, blocks are numbered sequentially, and then this block number is combined with an initialization vector (IV) and encrypted with a block cipher E, usually AES. The result of this encryption is then XORed with the plaintext to produce the ciphertext. Like all counter modes, this is essentially a stream cipher, and so it is essential that a different IV is used for each stream that is encrypted.

The ciphertext blocks are considered coefficients of a polynomial which is then evaluated at a key-dependent point H, using finite field arithmetic. The result is then encrypted, producing an authentication tag that can be used to verify the integrity of the data. The encrypted text then contains the IV, ciphertext, and authentication tag.

GCM operation. For simplicity, a case with only a single block of additional authenticated data (labeled Auth Data 1) and two blocks of plaintext is shown.
Encryption: A series of 128-bit counters is encrypted using the block cipher E with key K; this can occur in parallel. The results are combined using bitwise XOR with 128-bit plaintext blocks, producing a series of ciphertext blocks.
Authentication: The Additional Data and these ciphertext blocks are combined using multiplication with a key-dependent constant H in the Galois field GF(2128) to produce the authentication tag.

Mathematical basis

[edit]

GCM combines the well-known counter mode of encryption with the new Galois mode of authentication. The key feature is the ease of parallel computation of the Galois field multiplication used for authentication. This feature permits higher throughput than encryption algorithms, like CBC, which use chaining modes. The GF(2128) field used is defined by the polynomial

The authentication tag is constructed by feeding blocks of data into the GHASH function and encrypting the result. This GHASH function is defined by

where H = Ek(0128) is the hash key, a string of 128 zero bits encrypted using the block cipher, A is data which is only authenticated (not encrypted), C is the ciphertext, m is the number of 128-bit blocks in A (rounded up), n is the number of 128-bit blocks in C (rounded up), and the variable Xi for i = 0, ..., m + n + 1 is defined below.[3]

First, the authenticated text and the cipher text are separately zero-padded to multiples of 128 bits and combined into a single message Si:

where len(A) and len(C) are the 64-bit representations of the bit lengths of A and C, respectively, v = len(A) mod 128 is the bit length of the final block of A, u = len(C) mod 128 is the bit length of the final block of C, and denotes concatenation of bit strings.

Then Xi is defined as:

The second form is an efficient iterative algorithm (each Xi depends on Xi−1) produced by applying Horner's method to the first. Only the final Xm+n+1 remains an output.

If it is necessary to parallelize the hash computation, this can be done by interleaving k times:

If the length of the IV is not 96, the GHASH function is used to calculate Counter 0:

GCM was designed by John Viega and David A. McGrew to be an improvement to Carter–Wegman counter mode (CWC mode).[4]

In November 2007, NIST announced the release of NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC making GCM and GMAC official standards.[5]

Use

[edit]

GCM mode is used in the IEEE 802.1AE (MACsec) Ethernet security, WPA3-Enterprise Wifi security protocol, IEEE 802.11ad (also dubbed WiGig), ANSI (INCITS) Fibre Channel Security Protocols (FC-SP), IEEE P1619.1 tape storage, IETF IPsec standards,[6][7] SSH,[8] TLS 1.2[1][9] and TLS 1.3.[10] AES-GCM is included in the NSA Suite B Cryptography and its latest replacement in 2018 Commercial National Security Algorithm (CNSA) suite.[11] GCM mode is used in the SoftEther VPN server and client,[12] as well as OpenVPN since version 2.4.

Performance

[edit]

GCM requires one block cipher operation and one 128-bit multiplication in the Galois field per each block (128 bit) of encrypted and authenticated data. The block cipher operations are easily pipelined or parallelized; the multiplication operations are easily pipelined and can be parallelized with some modest effort (either by parallelizing the actual operation, by adapting Horner's method per the original NIST submission, or both).

Intel has added the PCLMULQDQ instruction, highlighting its use for GCM.[13] In 2011, SPARC added the XMULX and XMULXHI instructions, which also perform 64 × 64 bit carry-less multiplication. In 2015, SPARC added the XMPMUL instruction, which performs XOR multiplication of much larger values, up to 2048 × 2048 bit input values producing a 4096-bit result. These instructions enable fast multiplication over GF(2n), and can be used with any field representation.

Impressive performance results are published for GCM on a number of platforms. Käsper and Schwabe described a "Faster and Timing-Attack Resistant AES-GCM"[14] that achieves 10.68 cycles per byte AES-GCM authenticated encryption on 64-bit Intel processors. Dai et al. report 3.5 cycles per byte for the same algorithm when using Intel's AES-NI and PCLMULQDQ instructions. Shay Gueron and Vlad Krasnov achieved 2.47 cycles per byte on the 3rd generation Intel processors. Appropriate patches were prepared for the OpenSSL and NSS libraries.[15]

When both authentication and encryption need to be performed on a message, a software implementation can achieve speed gains by overlapping the execution of those operations. Performance is increased by exploiting instruction-level parallelism by interleaving operations. This process is called function stitching,[16] and while in principle it can be applied to any combination of cryptographic algorithms, GCM is especially suitable. Manley and Gregg[17] show the ease of optimizing when using function stitching with GCM. They present a program generator that takes an annotated C version of a cryptographic algorithm and generates code that runs well on the target processor.

GCM has been criticized in the embedded world (for example by Silicon Labs) because the parallel processing is not suited for performant use of cryptographic hardware engines. As a result, GCM reduces the performance of encryption for some of the most performance-sensitive devices.[18] Specialized hardware accelerators for ChaCha20-Poly1305 are less complex compared to AES accelerators.[19]

Patents

[edit]

According to the authors' statement, GCM is unencumbered by patents.[20]

Security

[edit]

GCM is proven secure in the concrete security model.[21] It is secure when it is used with a block cipher that is indistinguishable from a random permutation; however, security depends on choosing a unique initialization vector for every encryption performed with the same key (see stream cipher attack). For any given key and initialization vector value, GCM is limited to encrypting 239 − 256 bits of plain text (64 GiB). NIST Special Publication 800-38D[5] includes guidelines for initialization vector selection and limits the number of possible initialization vector values for a single key. As the security assurance of GCM degrades with more data being processed using the same key, the total number of blocks of plaintext and AD protected during the lifetime of a single key should be limited by 264.[5]

The authentication strength depends on the length of the authentication tag, like with all symmetric message authentication codes. The use of shorter authentication tags with GCM is discouraged. The bit-length of the tag, denoted t, is a security parameter. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key. Appendix C in NIST SP 800-38D provides guidance for these constraints (for example, if t = 32 and the maximal packet size is 210 bytes, the authentication decryption function should be invoked no more than 211 times; if t = 64 and the maximal packet size is 215 bytes, the authentication decryption function should be invoked no more than 232 times).

Like with any message authentication code, if the adversary chooses a t-bit tag at random, it is expected to be correct for given data with probability measure 2−t. With GCM, however, an adversary can increase their likelihood of success by choosing tags with n words – the total length of the ciphertext plus any additional authenticated data (AAD) – with probability measure 2−t by a factor of n. Although, one must bear in mind that these optimal tags are still dominated by the algorithm's survival measure 1 − n⋅2−t for arbitrarily large t. Moreover, GCM is neither well-suited for use with very short tag-lengths nor very long messages.

Ferguson and Saarinen independently described how an attacker can perform optimal attacks against GCM authentication, which meet the lower bound on its security. Ferguson showed that, if n denotes the total number of blocks in the encoding (the input to the GHASH function), then there is a method of constructing a targeted ciphertext forgery that is expected to succeed with a probability of approximately n⋅2−t. If the tag length t is shorter than 128, then each successful forgery in this attack increases the probability that subsequent targeted forgeries will succeed, and leaks information about the hash subkey, H. Eventually, H may be compromised entirely and the authentication assurance is completely lost.[22]

Independent of this attack, an adversary may attempt to systematically guess many different tags for a given input to authenticated decryption and thereby increase the probability that one (or more) of them, eventually, will be considered valid. For this reason, the system or protocol that implements GCM should monitor and, if necessary, limit the number of unsuccessful verification attempts for each key.

Saarinen described GCM weak keys.[23] This work gives some valuable insights into how polynomial hash-based authentication works. More precisely, this work describes a particular way of forging a GCM message, given a valid GCM message, that works with probability of about n⋅2−128 for messages that are n × 128 bits long. However, this work does not show a more effective attack than was previously known; the success probability in observation 1 of this paper matches that of lemma 2 from the INDOCRYPT 2004 analysis (setting w = 128 and l = n × 128). Saarinen also described a GCM variant Sophie Germain Counter Mode (SGCM) based on Sophie Germain primes.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Galois/Counter Mode

View on Grokipedia
from Grokipedia
Galois/Counter Mode (GCM) is a mode of operation for symmetric-key block ciphers that provides authenticated encryption with associated data (AEAD), combining counter mode for confidentiality and a universal hash function over the finite field GF(2128) for integrity and authenticity. Developed by David A. McGrew and John Viega and published in 2004, GCM was designed to support high-performance implementations in both hardware and software, enabling parallel processing and efficient authentication without additional passes over the data. It operates on a 128-bit block cipher, typically the Advanced Encryption Standard (AES), and produces a ciphertext along with an authentication tag to verify the integrity of the encrypted data and any associated unencrypted data. In GCM, encryption uses the block cipher in counter mode to generate a one-time pad keystream, which is XORed with the plaintext to produce the ciphertext, ensuring semantic security against chosen-plaintext attacks when a unique nonce is used. Authentication is achieved through the Galois Hash (GHASH) function, which processes the ciphertext, associated data, and length information in a single pass, followed by XORing the result with a counter-derived value to form the tag. This dual mechanism allows GCM to provide both encryption and message authentication in a single operation, making it suitable for resource-constrained environments while maintaining provable security bounds based on the underlying hash function's properties. The mode supports variable-length nonces (typically 96 bits) and authentication tags (up to 128 bits, commonly 128 or 96 bits), with a maximum plaintext length of about 64 gigabytes per invocation to preserve security. Standardized by the National Institute of Standards and Technology (NIST) in Special Publication 800-38D in 2007, with a revision in development as of 2025, GCM has become a cornerstone of modern cryptographic protocols due to its efficiency and simplicity. It is widely adopted in standards including Transport Layer Security (TLS) via RFC 5288, IPsec ESP in RFC 4106, and Secure Shell (SSH) in RFC 5647, often as AES-GCM for securing communications in web browsers, VPNs, and wireless networks. Its performance advantages, such as throughput exceeding 10 Gbps on suitable hardware, have made it the preferred AEAD scheme for high-speed applications, though careful nonce management is required to avoid security degradation from reuse.

Introduction

Definition and Purpose

Galois/Counter Mode (GCM) is a mode of operation for symmetric-key block ciphers that provides authenticated encryption with associated data (AEAD). It combines counter mode for encryption to ensure confidentiality with a Galois field-based universal hash function, known as GHASH, for authentication, enabling the generation of both ciphertext and an authentication tag in a single pass over the data. The primary purpose of GCM is to deliver high-speed, parallelizable encryption and authentication suitable for resource-constrained environments like network protocols, where both data privacy and integrity verification are essential. It supports variable-length inputs, including additional authenticated data (AAD) that receives integrity protection without encryption, making it versatile for protocols requiring data origin authentication alongside confidentiality. GCM is defined for use with approved 128-bit block ciphers, such as AES-128, AES-192, or AES-256, and recommends a 96-bit nonce length to optimize security, interoperability, and performance. Key benefits of GCM include its efficiency in software and hardware due to parallelizable operations in both the counter mode encryption and GHASH computation, achieving high throughput compared to modes requiring separate encryption and message authentication code (MAC) processes, such as CBC with HMAC. By integrating authentication, GCM resists certain attacks exploitable in unauthenticated modes like CBC, such as those relying on malleability or lack of integrity checks.

History and Development

Galois/Counter Mode (GCM) was developed in 2004 by David A. McGrew and John Viega at Cisco Systems, Inc., as an efficient authenticated encryption with associated data (AEAD) scheme that combines counter mode encryption with Galois field-based authentication, drawing on prior research in universal hashing and counter-based block cipher modes. The mode addressed the growing need for high-performance, parallelizable cryptographic primitives suitable for network protocols like IPsec and SSL/TLS, where both confidentiality and integrity were required without significant overhead. The initial specification appeared in a January 2004 submission to the NIST Modes of Operation Process, co-authored by McGrew and Viega, followed by a detailed security and performance analysis published later that year. This work motivated further IETF efforts, including a 2005 draft that outlined GCM's integration into IPsec Encapsulating Security Payload (ESP), culminating in RFC 4106. GCM's adoption accelerated with its standardization by NIST in Special Publication 800-38D in November 2007, which formalized the mode for use with the Advanced Encryption Standard (AES) and included its specialization, GMAC, for authentication only. Subsequent milestones included GCM's incorporation into Transport Layer Security (TLS) via RFC 5288 in August 2008, enabling AES-GCM cipher suites in TLS 1.2, and its mandatory support as an AEAD option in TLS 1.3 per RFC 8446 in August 2018. Post-publication refinements, including guidance on nonce management to mitigate reuse risks, appeared in protocol specifications and analyses. In March 2024, NIST announced plans to revise SP 800-38D, with a pre-draft call for comments issued in January 2025 proposing changes such as deprecating authentication tags shorter than 96 bits and updating security considerations. As of November 2025, GCM remains a foundational AEAD mode in widespread use across IPsec, TLS, and other standards.

Operational Mechanism

Counter Mode Encryption

Counter mode encryption in Galois/Counter Mode (GCM) provides confidentiality by transforming plaintext into ciphertext using a stream cipher derived from a block cipher in counter mode, ensuring semantic security under chosen-plaintext attacks when used with a unique nonce. The process generates a keystream by encrypting successive counter blocks with the secret key, which is then XORed with the plaintext blocks to produce the ciphertext. This approach allows for efficient encryption of messages of arbitrary length by dividing the plaintext into 128-bit blocks, with the final block XORed partially if necessary. The counter blocks are derived from an initialization vector (IV), typically a 96-bit nonce concatenated with a 32-bit counter value. Specifically, the initial counter block J0J_0 is formed as the 96-bit IV followed by 31 zero bits and a 1, represented as J0=IV∥031∥1J_0 = \text{IV} \| 0^{31} \| 1, where ∥\| denotes concatenation. Subsequent counter blocks are obtained by incrementing J0J_0 in big-endian integer arithmetic: the jj-th counter block is incrj(J0)\text{incr}^j (J_0), starting from j=1j = 1. The keystream block SjS_j is then computed as Sj=EK(incrj(J0))S_j = E_K (\text{incr}^j (J_0)), where EKE_K is the block cipher encryption under key KK. For a plaintext PP of length mm bits, divided into u=⌈m/128⌉u = \lceil m / 128 \rceil blocks P1,…,PuP_1, \dots, P_u, the ciphertext blocks are Ci=Pi⊕SiC_i = P_i \oplus S_i for i=1i = 1 to u−1u-1, and for the last block, only the first mmod  128m \mod 128 bits are XORed if partial. If the IV is not 96 bits, let s=128⌈len(IV)128⌉−len(IV)s = 128 \lceil \frac{\text{len(IV)}}{128} \rceil - \text{len(IV)}; then compute GHASHH(IV∥0s∥[len(IV)]64∥064)\text{GHASH}_H \left( \text{IV} \| 0^{s} \| [\text{len(IV)}]_{64} \| 0^{64} \right) to obtain a 128-bit value, and set J0=J_0 = that value ∥031∥1\| 0^{31} \| 1, though this is less efficient due to the additional hash computation. A subkey HH is derived solely for use in the mode's authentication component by setting H=EK(0128)H = E_K (0^{128}), where 01280^{128} is a 128-bit block of zeros; this same key KK is used for both the counter encryption and HH derivation. The counter mode's design supports high parallelization, as each keystream block SjS_j can be computed independently by encrypting the corresponding counter block in any order, enabling efficient implementation on multi-core processors or hardware accelerators for high-throughput applications. This parallelism contributes to GCM's performance advantages over other authenticated encryption modes.

GHASH Authentication

In Galois/Counter Mode (GCM), authentication is provided by GHASH, a universal hash function that operates over the finite field GF(2^{128}) to compute an integrity tag over both the additional authenticated data (AAD) and the ciphertext. This mechanism ensures that any alteration to the protected data or AAD can be detected with high probability, without requiring decryption of the ciphertext during verification. The hash subkey HH, derived by encrypting a zero-filled 128-bit block with the underlying block cipher under the session key, serves as the fixed multiplier in the hashing process. The input to GHASH is a concatenated bit string formed from the AAD AA, the ciphertext CC, and their lengths. Both AA and CC are treated as bit strings and zero-padded with the minimal number of bits (denoted as 0a0^{a} for AAD and 0c0^{c} for ciphertext) to reach lengths that are multiples of 128 bits, resulting in vv and uu full 128-bit blocks respectively. The full input XX is then X=A∥0a∥C∥0c∥[∣A∣]64∥[∣C∣]64X = A \| 0^{a} \| C \| 0^{c} \| [|A|]_{64} \| [|C|]_{64}, where ∣A∣|A| and ∣C∣|C| are the bit lengths of the AAD and ciphertext, represented as 64-bit big-endian integers and appended as additional 128-bit blocks. This formatting ensures that GHASH processes all relevant data uniformly, covering unprotected AAD alongside the encrypted payload. The computation of GHASH treats XX as a sequence of mm 128-bit blocks X1,X2,…,XmX_1, X_2, \dots, X_m, and evaluates the polynomial hash: GHASHH(X)=X1⋅Hm⊕X2⋅Hm−1⊕⋯⊕Xm⋅H\text{GHASH}_H(X) = X_1 \cdot H^m \oplus X_2 \cdot H^{m-1} \oplus \cdots \oplus X_m \cdot H where all operations, including multiplication ⋅\cdot and addition (XOR) ⊕\oplus, occur in GF(2^{128}). In practice, this is computed iteratively for efficiency: initialize Y0=0128Y_0 = 0^{128}, then for i=1i = 1 to mm, set Yi=(Yi−1⊕Xi)⋅HY_i = (Y_{i-1} \oplus X_i) \cdot H, with the output being YmY_m. This structure leverages the algebraic properties of the field to produce a 128-bit hash value. The multiplicative nature of GHASH, rooted in field multiplication, underpins its security as a universal hash function, ensuring that for distinct inputs, the probability of collision is at most 2−1282^{-128} when the hash subkey HH is unpredictable from the adversary's perspective. This property enables efficient authentication with provable bounds on forgery success, assuming the underlying block cipher is pseudorandom.

Tag Generation and Verification

In Galois/Counter Mode (GCM), the authentication tag TT is generated during authenticated encryption by computing the GHASH function over the associated authenticated data (AAD) AA, the ciphertext CC, and their bit lengths, then XORing the result with the block cipher encryption of the initial counter block J0J_0. Specifically, the input to GHASH is the concatenation A∥0a∥C∥0c∥[len(A)]64∥[len(C)]64A \Vert 0^{a} \Vert C \Vert 0^{c} \Vert [\text{len}(A)]_{64} \Vert [\text{len}(C)]_{64}, where aa (respectively, cc) is the minimum number of bits needed to pad AA (respectively, CC) to a multiple of 128 bits, 0a0^{a} denotes a string of aa zero bits, and [⋅]64[\cdot]_{64} represents the 64-bit binary representation of the length. The tag is then T=MSBt(GHASHH(⋅)⊕EK(J0))T = \text{MSB}_t \left( \text{GHASH}_H(\cdot) \oplus E_K(J_0) \right), where HH is the fixed hash subkey derived from the cipher key KK, EKE_K is the block cipher encryption under KK, J0J_0 is the initial counter block (for a typical 96-bit IV, J0=IV∥031∥1J_0 = \text{IV} \Vert 0^{31} \Vert 1; for other lengths, as defined in the Counter Mode Encryption subsection), and t is the tag length in bits (supported values: 32, 64, 96, 104, 112, 120, 128), with MSB_t denoting the most significant t bits of the 128-bit value. During authenticated decryption, the receiver recomputes GHASH using the provided AAD, received ciphertext, and lengths, then computes the candidate tag as MSBt(GHASHH(⋅)⊕EK(J0))\text{MSB}_t \left( \text{GHASH}_H(\cdot) \oplus E_K(J_0) \right) and checks if it matches the received tag TT exactly; if the values match, the message is accepted and the plaintext is released, otherwise it is rejected to prevent processing of tampered data. GCM achieves single-pass efficiency by parallelizing the counter-mode encryption of the plaintext (to produce ciphertext) with the GHASH computation over the AAD and accumulating ciphertext blocks, allowing both operations to proceed concurrently before finalizing the tag at the end of processing. On decryption, tag verification occurs prior to plaintext recovery, ensuring integrity checks precede confidentiality release. The mode supports AAD lengths up to 264−12^{64} - 1 bits and ciphertext lengths up to (232−2)×128(2^{32} - 2) \times 128 bits per nonce to avoid counter overflow and maintain security bounds. Nonce reuse in GCM results in catastrophic failure, enabling attackers to forge arbitrary messages or recover keys.

Mathematical Foundations

Galois Field GF(2^128)

Galois/Counter Mode (GCM) relies on arithmetic in the finite field GF(2^{128}), which consists of 2^{128} elements and is constructed as the ring of polynomials over GF(2) modulo an irreducible polynomial of degree 128. Specifically, GF(2^{128}) = GF(2) / (p(x)), where p(x) = x^{128} + x^7 + x^2 + x + 1. This particular irreducible polynomial is primitive, ensuring the field has the desired cyclic structure, and was chosen for its compatibility with AES block sizes and its low Hamming weight, which enables efficient hardware implementations of field operations. Elements of GF(2^{128}) are represented as 128-bit binary strings, interpreted as polynomials of degree at most 127 with coefficients in {0,1}. The representation uses little-endian byte ordering, where the bytes are arranged from least to most significant, and within each byte, the bits correspond to polynomial coefficients with the least significant bit as the coefficient of the lowest power (x^0 for the overall least significant bit). This convention aligns the bit string directly with standard 128-bit register or memory layouts for computational efficiency. Addition in GF(2^{128}) is simply the bitwise XOR operation on the 128-bit representations, reflecting the characteristic 2 of the field where 1 + 1 = 0. Multiplication is defined as the multiplication of the corresponding polynomials followed by reduction modulo p(x). The polynomial multiplication step produces a result of degree up to 254 and is computed using carry-less multiplication, which avoids carries and can be accelerated by dedicated hardware instructions such as Intel's PCLMULQDQ. The reduction modulo p(x) after multiplication involves XORing the higher-degree terms with appropriately shifted versions of the original product, leveraging the specific form of p(x) to minimize operations. For instance, if the product has terms of degree 128 or higher, those bits are XORed with the corresponding shifts of the lower bits according to the polynomial's coefficients at degrees 7, 2, 1, and 0. This process ensures the result remains a polynomial of degree less than 128. Although multiplicative inverses exist in GF(2^{128}) and can be computed using the extended Euclidean algorithm adapted for polynomials, they are not utilized in GCM's core operations.

Hash Function GHASH

The GHASH function serves as the core authentication primitive in Galois/Counter Mode (GCM), operating as a keyed universal hash function defined over the binary Galois field GF(2^{128}). It processes input data divided into 128-bit blocks and computes a 128-bit hash value through multiplications and additions in this field. The function is designed to provide strong collision resistance when the key-derived parameter is treated as random, contributing to the overall security of authenticated encryption in GCM. Formally, for an input string AA consisting of mm 128-bit blocks X1,X2,…,XmX_1, X_2, \dots, X_m, the GHASH function with key parameter HH is defined as GHASHH(A)=∑i=1mXi⋅Hm+1−i,\text{GHASH}_H(A) = \sum_{i=1}^m X_i \cdot H^{m+1-i}, where all operations are performed in GF(2^{128}), ⋅\cdot denotes field multiplication, and ++ denotes bitwise XOR (the field's addition operation). This polynomial evaluation ensures that distinct inputs produce distinct outputs with high probability under a random HH. An equivalent and computationally efficient form uses Horner's method for iterative evaluation: initialize Y0=0128Y_0 = 0^{128}, then for i=1i = 1 to mm, compute Yi=(Yi−1⊕Xi)⋅HY_i = (Y_{i-1} \oplus X_i) \cdot H, yielding GHASHH(A)=Ym\text{GHASH}_H(A) = Y_m. This avoids explicit computation of high powers of HH and requires exactly mm field multiplications. GHASH belongs to the family of Wegman-Carter polynomial hashes, exhibiting strong universality: for any two distinct inputs A≠A′A \neq A', the probability that GHASHH(A)=GHASHH(A′)\text{GHASH}_H(A) = \text{GHASH}_H(A') is at most 2−1282^{-128} when HH is chosen uniformly at random from GF(2^{128}). This property bounds the adversary's success probability in forging a valid authentication tag, providing 128 bits of security against collisions in the ideal case. The keyed nature of GHASH derives from HH, which is generated as the block cipher encryption of the all-zero string under the session key kk: H=Ek(0128)H = E_k(0^{128}). Since a secure block cipher behaves as a pseudorandom permutation, HH appears random to an adversary without knowledge of kk, preserving the universality guarantees in practice. Powers of HH (if needed in alternative implementations) can be computed efficiently using repeated squaring, which requires O(log⁡i)O(\log i) multiplications for HiH^i, or via precomputed tables for small exponents in hardware-optimized settings. To handle inputs not aligned to 128-bit boundaries, GHASH employs explicit zero-padding: the bit string is appended with sufficient zero bits to reach the next multiple of 128 bits, ensuring the input forms complete blocks without altering the hash properties. This padding is deterministic and preserves the universality, as it maps variable-length inputs to fixed-block representations injectively for distinct originals. The overall time complexity of GHASH is linear in the input size, O(n)O(n) for an nn-bit input (with n/128n/128 field multiplications), making it suitable for high-throughput applications. Field operations, such as multiplication, rely on the irreducible polynomial defined for GF(2^{128}) (as detailed in the mathematical foundations of GCM), typically implemented via carry-less multiplication followed by reduction. Parallelization is possible by precomputing multiples of HH or using vectorized instructions for independent block processing in the iterative form.

Implementation Aspects

Algorithm Steps

The Galois/Counter Mode (GCM) algorithm provides authenticated encryption with associated data (AEAD) using a block cipher, typically AES-128, AES-192, or AES-256, operating on 128-bit blocks. The process involves two main phases: encryption, which generates the ciphertext and authentication tag, and decryption, which verifies the tag before recovering the plaintext. All operations are performed in the finite field GF(2^{128}), with bit-level padding applied to inputs as needed to align with 128-bit block boundaries by appending zeros. The key derivation for the hash subkey H and the initial counter block J_0 are foundational to both phases.

Encryption Procedure

The encryption process begins by deriving the hash subkey H from the secret key K using the block cipher E: compute H = E_K(0^{128}), where 0^{128} denotes a 128-bit zero block. This H is used solely for the GHASH authentication function and is precomputed once per key. Next, form the initial counter block J_0 by concatenating the initialization vector IV (typically 96 bits) with 31 zero bits followed by a 1-bit counter value, yielding J_0 = IV || 0^{31} || 1 (expressed in 128 bits). If the IV length differs from 96 bits, let s be the bit length needed to pad IV to the next multiple of 128 bits, then compute the GHASH input as IV || 0^s || 0^{64} || [len(IV)]{64}, where [len(IV)]{64} is the 64-bit big-endian representation of the IV length in bits, and set J_0 = GHASH_H(that input) || 0^{31} || 1, but the 96-bit case is standard for efficiency. To generate the keystream, increment J_0 to produce subsequent counter blocks. For a plaintext P of length up to 2^{64}-1 bits divided into m 128-bit blocks P_1, ..., P_m (with the last block potentially partial and zero-padded if necessary), compute the i-th counter block starting from inc_{32}(J_0), where inc_{32} increments the rightmost 32 bits of J_0 by 1 (with carry propagating left if needed), and subsequent blocks increment further. Encrypt each counter block to obtain the keystream block: S_i = E_K( inc_{32}(J_0) + (i-1) ) for i = 1 to m, where + denotes incrementing the 32-bit counter portion. The ciphertext blocks are then C_i = P_i \oplus S_i for i = 1 to m-1, and for the final block, C_m = P_m \oplus S_m truncated to the actual plaintext length (padding bits are not transmitted). The full ciphertext C is the concatenation C_1 || ... || C_m. Authentication proceeds via GHASH, which hashes the associated data A (padded to a multiple of 128 bits with zeros, denoted A^), the ciphertext C (padded similarly to C^), and the 128-bit length block containing the bit lengths of A and C in big-endian 64-bit fields: len(A) || len(C). The input to GHASH is the concatenation A^* || C^* || [len(A)]{64} || [len(C)]{64}, and the GHASH output is computed iteratively over these 128-bit blocks using the polynomial multiplication in GF(2^{128}) with H. The authentication tag T of length t bits (commonly 128, 120, 112, 104, or 96) is derived as the most significant t bits of the GHASH result XORed with the encryption of J_0: T = MSB_t( GHASH(AAD, C, len) \oplus E_K(J_0) ). The final output is the IV, C, and T. Here is pseudocode for the GCM encryption algorithm:

GCM-Encrypt(K, IV, A, P, t) // Key K, IV (96 bits), AAD A, plaintext P, tag length t in bits 1. H ← E_K(0^{128}) 2. if len(IV) = 96 then J_0 ← IV || 0^{31} || 1 else s ← 128 * ceil(len(IV)/128) - len(IV) IV_padded ← IV || 0^s GHASH_input ← IV_padded || 0^{64} || [len(IV)]_{64} J_0 ← GHASH(H, GHASH_input) || 0^{31} || 1 3. S ← E_K(J_0) // For tag 4. m ← ceil(len(P)/128) // Number of plaintext blocks 5. for i = 1 to m do Inc ← inc_{32}(J_0) + (i-1) // Increment 32-bit counter part by (i-1) from inc_32(J_0) S_i ← E_K(Inc) C_i ← P_i ⊕ S_i // P_i is 128-bit block, last may be partial 6. C ← C_1 || ... || C_m // Truncate last block to actual length 7. A^* ← pad(A) // Append 0s to multiple of 128 bits 8. C^* ← pad(C) 9. len_block ← [len(A)]_{64} || [len(C)]_{64} // Big-endian 10. AA ← A^* || C^* || len_block 11. G ← GHASH(H, AA) // Iterative: X_0 = 0, X_{i} = (X_{i-1} ⊕ AA_i) ⋅ H for each block AA_i 12. T ← MSB_t( G ⊕ S ) 13. return IV || C || T

GCM-Encrypt(K, IV, A, P, t) // Key K, IV (96 bits), AAD A, plaintext P, tag length t in bits 1. H ← E_K(0^{128}) 2. if len(IV) = 96 then J_0 ← IV || 0^{31} || 1 else s ← 128 * ceil(len(IV)/128) - len(IV) IV_padded ← IV || 0^s GHASH_input ← IV_padded || 0^{64} || [len(IV)]_{64} J_0 ← GHASH(H, GHASH_input) || 0^{31} || 1 3. S ← E_K(J_0) // For tag 4. m ← ceil(len(P)/128) // Number of plaintext blocks 5. for i = 1 to m do Inc ← inc_{32}(J_0) + (i-1) // Increment 32-bit counter part by (i-1) from inc_32(J_0) S_i ← E_K(Inc) C_i ← P_i ⊕ S_i // P_i is 128-bit block, last may be partial 6. C ← C_1 || ... || C_m // Truncate last block to actual length 7. A^* ← pad(A) // Append 0s to multiple of 128 bits 8. C^* ← pad(C) 9. len_block ← [len(A)]_{64} || [len(C)]_{64} // Big-endian 10. AA ← A^* || C^* || len_block 11. G ← GHASH(H, AA) // Iterative: X_0 = 0, X_{i} = (X_{i-1} ⊕ AA_i) ⋅ H for each block AA_i 12. T ← MSB_t( G ⊕ S ) 13. return IV || C || T

Note that the GHASH function is defined as GHASH(H, A) = \bigoplus_{i=0}^{n} (A_i \cdot H^{n-i}), but implemented iteratively to avoid exponentiation, with ⋅ denoting multiplication in GF(2^{128}) reduced modulo the AES field polynomial.

Decryption Procedure

Decryption mirrors encryption but prioritizes tag verification before plaintext recovery to ensure authenticity. Using the received IV, A, C, and T, first recompute H = E_K(0^{128}) and J_0 as in encryption. Then, compute the GHASH on the received A (padded), C (padded), and lengths exactly as during encryption to obtain G. The expected tag is T' = MSB_t( G \oplus E_K(J_0) ). If T ≠ T', the message is rejected immediately, with no plaintext released to prevent partial decryption attacks; the implementation must abort without outputting any data. Modern implementations (as of 2025) incorporate side-channel protections, such as constant-time tag comparison using functions like CMP-CT (constant-time memory-secure equality check) to avoid timing leaks. If the tag verifies, generate the keystream blocks S_i = E_K( Inc_{32}(J_0) + (i-1) ) for i = 1 to m, where m = ceil(len(C)/128), and recover P_i = C_i \oplus S_i for each block, truncating the final block to the known length. The full plaintext P is the concatenation of these blocks. No further error handling is specified beyond the initial tag check, assuming the ciphertext length is valid. Pseudocode for GCM decryption:

GCM-Decrypt(K, IV, A, C, T, t) // Inputs as in encryption, received T of t bits 1. H ← E_K(0^{128}) 2. J_0 ← form as in encryption using IV 3. S ← E_K(J_0) 4. A^* ← pad(A) 5. C^* ← pad(C) 6. len_block ← [len(A)]_{64} || [len(C)]_{64} 7. AA ← A^* || C^* || len_block 8. G ← GHASH(H, AA) 9. T' ← MSB_t( G ⊕ S ) 10. if T' ≠ T then return ⊥ // Reject, abort (use constant-time comparison) 11. m ← ceil(len(C)/128) 12. for i = 1 to m do Inc ← inc_{32}(J_0) + (i-1) // Increment 32-bit counter part by (i-1) from inc_32(J_0) S_i ← E_K(Inc) P_i ← C_i ⊕ S_i 13. P ← P_1 || ... || P_m // Truncate last to len(C) 14. return P

GCM-Decrypt(K, IV, A, C, T, t) // Inputs as in encryption, received T of t bits 1. H ← E_K(0^{128}) 2. J_0 ← form as in encryption using IV 3. S ← E_K(J_0) 4. A^* ← pad(A) 5. C^* ← pad(C) 6. len_block ← [len(A)]_{64} || [len(C)]_{64} 7. AA ← A^* || C^* || len_block 8. G ← GHASH(H, AA) 9. T' ← MSB_t( G ⊕ S ) 10. if T' ≠ T then return ⊥ // Reject, abort (use constant-time comparison) 11. m ← ceil(len(C)/128) 12. for i = 1 to m do Inc ← inc_{32}(J_0) + (i-1) // Increment 32-bit counter part by (i-1) from inc_32(J_0) S_i ← E_K(Inc) P_i ← C_i ⊕ S_i 13. P ← P_1 || ... || P_m // Truncate last to len(C) 14. return P

This procedure ensures that only authenticated messages are decrypted, with all padding handled internally without affecting the output lengths.

Performance Characteristics

Galois/Counter Mode (GCM) achieves high throughput on modern processors equipped with hardware acceleration for AES and Galois field multiplication. With Intel AES-NI instructions introduced in 2010 and PCLMULQDQ for efficient GHASH computation, AES-128-GCM can exceed 10 GB/s in software on multi-core CPUs, while AMD processors with equivalent extensions since around 2012 and ARMv8 cryptography extensions from 2015 enable similar rates on server-grade hardware. The single-pass design of GCM, which interleaves encryption and authentication, reduces overall latency compared to separate Encrypt-then-MAC constructions like AES-CTR with HMAC-SHA256, avoiding sequential processing overhead. The Counter Mode component of GCM supports full parallelization across blocks, as each counter-derived keystream can be generated independently, while GHASH authentication benefits from vectorized implementations of Galois field multiplications using SIMD instructions like AVX2 or NEON. This makes GCM well-suited for multi-core environments, where workloads can be distributed to achieve linear scaling in throughput for large data volumes. GCM maintains minimal resource usage, requiring only the secret key, a precomputed hash subkey H (derived once as AES encryption of a zero block), and a per-message nonce for initialization; no extensive precomputation tables or large buffers are needed beyond input data. In software benchmarks, AES-GCM demonstrates superior efficiency over AES-CCM, outperforming it significantly in encryption and authentication tasks on platforms without dedicated hardware, with speedups attributed to GCM's parallel-friendly structure and lower computational complexity for GHASH versus CCM's CBC-MAC. NIST evaluations and independent tests confirm AES-GCM's advantages in resource-constrained software environments. Hardware accelerations further enhance GCM in TLS offload engines, such as those in NVIDIA BlueField DPUs or Chelsio adapters, enabling line-rate processing up to 100 Gbps for encrypted sessions by dedicating silicon to AES-CTR and GHASH operations. On low-end devices lacking carry-less multiplication instructions like PCLMULQDQ or ARM PMULL, GCM performance degrades due to the computational intensity of GHASH polynomial multiplications in software, often bottlenecking overall throughput to below 1 GB/s. Recent ARMv9 architecture extensions, including enhanced cryptography instructions, provide incremental boosts to GCM efficiency on compatible processors, though specific gains vary by implementation. Compared to plain AES-CTR mode, GCM incurs approximately 10-20% additional overhead from GHASH computations, a trade-off for integrated authentication without substantially impacting high-throughput scenarios.

Applications

Standards and Protocols

Galois/Counter Mode (GCM) is formally specified in NIST Special Publication 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC," published in November 2007. NIST announced plans to revise the publication in March 2024, with a pre-draft call for comments issued in January 2025; proposed changes include removing support for authentication tags shorter than 96 bits. This standard defines GCM as an approved mode for authenticated encryption with associated data (AEAD) when used with approved block ciphers such as AES, providing both confidentiality and integrity protection for sensitive data in federal systems. The Internet Engineering Task Force (IETF) has integrated GCM into several key protocols through dedicated RFCs. RFC 4106, published in June 2005, specifies the use of AES in GCM mode (AES-GCM) within IPsec Encapsulating Security Payload (ESP) for providing confidentiality and data origin authentication in VPNs and secure communications. Similarly, RFC 4543, from May 2006, extends this by defining the application of AES Galois Message Authentication Code (GMAC, a component of GCM) in IPsec ESP and Authentication Header (AH) for integrity without encryption. For Transport Layer Security (TLS), RFC 5288, issued in August 2008, introduces AES-GCM cipher suites for TLS, enabling authenticated encryption in versions up to TLS 1.2. In TLS 1.3, defined by RFC 8446 in August 2018, AES-128-GCM is mandatory to implement, making it a core component of modern web security. Beyond IETF standards, GCM appears in various other protocols. IEEE 802.1AE, the MAC Security (MACsec) standard ratified in 2006 and amended in subsequent years (e.g., 802.1AEbn-2011 for GCM-AES-256), mandates GCM-AES-128 as the default cipher suite for securing Ethernet frames at Layer 2, ensuring data confidentiality and integrity in data center and enterprise networks. The Wi-Fi Alliance's WPA3 certification, introduced in 2018 and based on IEEE 802.11 amendments, incorporates AES-GCM in enterprise mode for robust Wi-Fi encryption and authentication. For Secure Shell (SSH), RFC 5647 from August 2009 outlines AES-GCM usage in the SSH Transport Layer Protocol to combine encryption and integrity in remote access scenarios. By 2021, QUIC—the transport protocol underlying HTTP/3—was secured via TLS 1.3 in RFC 9001, inherently supporting AES-GCM for low-latency, encrypted web traffic. A notable variant, AES-GCM-SIV, addresses nonce reuse vulnerabilities in standard GCM by providing misuse-resistant authenticated encryption; it is specified in RFC 8452, published in April 2019, and recommended for applications requiring deterministic nonces, such as disk encryption. GCM enjoys widespread global adoption, serving as the default AEAD mechanism in most VPN implementations (e.g., via IPsec), HTTPS servers, and secure protocols. As of February 2024, TLS 1.3—predominantly using AES-GCM cipher suites—comprises more than 93% of all TLS traffic, underscoring its dominance in securing the majority of internet communications.

Advantages over Other Modes

Galois/Counter Mode (GCM) provides several key advantages over other authenticated encryption with associated data (AEAD) modes, particularly in terms of performance, flexibility, and standardization suitability. Compared to Counter with CBC-MAC (CCM), GCM enables parallel processing for both encryption and authentication, as its counter mode encryption and GHASH authentication can be computed independently across blocks, leading to higher throughput in high-speed applications. In contrast, CCM's use of CBC-MAC for authentication requires sequential processing, limiting its efficiency on modern hardware. Additionally, GCM authenticates the ciphertext rather than the plaintext, offering stronger integrity protection against certain tampering attempts during transmission. Relative to Offset Codebook (OCB) mode, GCM has been free of intellectual property encumbrances since its inception, facilitating widespread adoption in standards without licensing concerns, whereas OCB's patents were only fully resolved through abandonment in 2021. Although OCB can achieve slightly higher software performance in some scenarios due to its single-pass design without separate hashing, GCM's integration into hardware instructions like Intel's AES-NI and VAES provides superior efficiency in accelerated environments. When contrasted with Cipher Block Chaining (CBC) combined with HMAC, GCM operates in a single pass over the data for both confidentiality and authenticity, whereas CBC+HMAC requires two separate passes—one for encryption and one for MAC computation—resulting in lower overall efficiency and reduced parallelism. GCM's fixed 128-bit tag length also simplifies implementation compared to HMAC's variable output sizes, though it uses a single key for both operations. GCM's unique strengths include its provable security as an AEAD scheme under standard assumptions, with bounds on privacy and authenticity derived from the underlying block cipher's pseudorandomness. It employs a nonce-based design that avoids the need for IV synchronization required in modes like CBC, reducing overhead in protocols. Widespread hardware acceleration further enhances its practicality across diverse platforms. However, GCM is highly sensitive to nonce reuse, which can compromise both confidentiality and authenticity under the same key, unlike some modes with built-in misuse resistance. It also lacks inherent resistance to key or nonce misuse without additional protocol-level protections. From a 2025 perspective, AES-GCM remains the preferred choice for high-speed network applications, such as TLS in bandwidth-constrained but hardware-accelerated environments, outperforming ChaCha20-Poly1305 where AES instructions are available, though the latter excels in pure software scenarios.

Security Considerations

Security Proofs

The security proofs for Galois/Counter Mode (GCM) establish its properties as an authenticated encryption with associated data (AEAD) scheme in the standard model of concrete security. These proofs reduce the security of GCM to the pseudorandom function (PRF) assumption on the underlying block cipher and the almost-universality of the GHASH function. The analysis assumes an ideal cipher and a random hash subkey HH, with distinct nonces across queries to prevent catastrophic failures. For indistinguishability (privacy), GCM inherits the security of counter mode under the PRF assumption on the block cipher, yielding a distinguishing advantage of at most the PRF advantage plus approximately (σ+q)22129\frac{(\sigma + q)^2}{2^{129}}, where qq is the number of encryption queries and σ\sigma the total number of blocks processed. For authentication, the forgery probability is bounded by the PRF advantage plus approximately (τ+q)22129\frac{(\tau + q)^2}{2^{129}} from GHASH collisions in addition to linear terms accounting for forgery attempts (such as q⋅ℓ/2tq \cdot \ell / 2^{t}, where ℓ\ell is related to the message length in blocks), where τ\tau is the total number of blocks of ciphertext and associated data across queries, qq the number of forgery attempts, and tt the tag length, relying on GHASH as an ε\varepsilon-almost universal hash function with ε≈2−128\varepsilon \approx 2^{-128}. This bound holds under the assumption that the block cipher behaves ideally and HH is uniformly random. The proof structure originates from McGrew and Viega's analysis (INDOCRYPT 2004) extended in NIST SP 800-38D (2007); however, the original analysis contained flaws in collision probability estimation that were repaired in subsequent work such as Iwata et al. (2012). Tag truncation affects authentication security: reducing the tag length to tt bits (e.g., 96 or 64 bits) elevates the forgery probability to approximately n⋅2−tn \cdot 2^{-t} via structured/targeted attacks (where nn is the number of blocks in the encoding of ciphertext and AAD), in addition to random guessing at 2−t2^{-t}; such reductions require strict limits on message lengths and key lifetimes as per NIST guidelines and are recommended only for low-security applications. The bounds assume the 96-bit nonce format, with at most 2322^{32} messages encrypted per key to avoid counter wrap-around, which could otherwise degrade security by enabling collisions in the counter values.

Potential Attacks and Mitigations

One of the primary vulnerabilities in Galois/Counter Mode (GCM) arises from nonce reuse under the same key, which completely compromises both confidentiality and authenticity. When two messages are encrypted with the same nonce and key, an attacker can recover the plaintext of one message by XORing the corresponding ciphertexts, as the counter mode keystream cancels out. This also allows recovery of the hash subkey H used in GHASH, enabling arbitrary forgery of authenticated ciphertexts. In TLS deployments, random nonce generation exacerbates the risk, with a 40% probability of reuse after approximately 2^{32} records, affecting thousands of servers. To mitigate this, nonces must be unique for each encryption with a fixed key, typically using a 96-bit nonce with a 32-bit counter; keys should be rotated after processing around 2^{32} packets to bound the birthday collision probability. Timing attacks target the variable execution time in GHASH computations, particularly the GF(2^{128}) multiplication, which can leak information about the hash subkey or plaintext through cache or branch predictions. Implementations using table lookups for polynomial multiplication are especially susceptible, allowing attackers to distinguish valid from invalid authentications. Mitigation involves constant-time implementations, such as bit-sliced AES and masked Karatsuba multiplication for GHASH, often leveraging Intel intrinsics like PCLMULQDQ for efficient, side-channel-resistant operations. These approaches ensure uniform execution paths without performance degradation on modern hardware. Known implementation flaws have exposed GCM in specific protocols. The 2013 Lucky Thirteen attack, while primarily targeting CBC modes in TLS via padding oracle timing, highlighted broader decryption timing vulnerabilities that influenced GCM adoption; mitigations like limiting TLS record sizes to 2^{14} bytes and constant-time processing were applied to prevent similar oracle attacks in AEAD modes. Side-channel attacks, such as cache-timing on the AES-CTR component, exploit data-dependent memory accesses in S-box lookups, potentially recovering round keys from shared cache contention between processes. GHASH can also suffer cache collisions during table-based multiplications. As of 2025, mitigations include running GCM in Intel SGX enclaves to isolate cache access or using dedicated hardware accelerators like AES-NI with constant-time guarantees to minimize leakage. Recent analyses (as of 2024) have examined collision-based attacks in multi-user scenarios with specific IV constructions, reinforcing the need for unique nonces. In 2025, a flaw in Ruby's JWE library (CVE-2025-54887) allowed bypassing AES-GCM tag validation, underscoring the importance of secure implementations. GCM's reliance on AES makes it vulnerable to quantum attacks via Grover's algorithm, which quadratically reduces the effective security of AES-128 to 64 bits, potentially allowing key search in feasible time on large-scale quantum computers. While AES-256 offers 128-bit quantum security, long-term migration to post-quantum authenticated encryption schemes, such as hybrids combining ML-KEM (Kyber) key encapsulation with AES-GCM, is recommended for forward secrecy. Best practices for secure GCM deployment emphasize strict adherence to standards: never reuse a nonce-key pair, as it nullifies security guarantees; always use 128-bit authentication tags to maintain full integrity protection; and validate associated data and ciphertext lengths before processing to prevent length extension or truncation exploits. These measures, when combined with nonce randomization or counter-based generation, align with GCM's security bounds under ideal conditions. The developers of Galois/Counter Mode (GCM), David A. McGrew and John Viega, have stated that they are unaware of any intellectual property rights pertaining to the mode and do not claim any such rights themselves. A key design goal of GCM was to avoid intellectual property encumbrances to facilitate widespread adoption. GCM is based on established cryptographic techniques, including counter mode and universal hashing, which predate its development and are not subject to patents that would restrict its use. As a result, GCM is freely available for implementation in both open-source and commercial products without licensing requirements.

References

  1. https://csrc.nist.gov/pubs/sp/800/38/d/final
  2. https://eprint.iacr.org/2004/193
  3. https://cr.yp.to/bib/2004/mcgrew-gcm.pdf
  4. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
  5. https://csrc.nist.gov/pubs/sp/800/38/d/r1/iprd
  6. https://datatracker.ietf.org/doc/html/rfc5288
  7. https://datatracker.ietf.org/doc/html/rfc4106
  8. https://datatracker.ietf.org/doc/html/rfc5647
  9. https://www.nsf.gov/events/gcm-encryption-authentication-10-gbps-beyond
  10. https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf
  11. https://datatracker.ietf.org/doc/rfc4106/
  12. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf
  13. https://datatracker.ietf.org/doc/rfc5288/
  14. https://csrc.nist.gov/news/2024/nist-to-revise-sp-80038d-gcm-and-gmac-modes
  15. https://eprint.iacr.org/2004/193.pdf
  16. https://cdrdv2-public.intel.com/836172/clmul-wp-rev-2-02-2014-04-20.pdf
  17. https://www.intel.com/content/dam/www/public/us/en/documents/software-support/enabling-high-performance-gcm.pdf
  18. https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-cryptographic-paper.pdf
  19. https://crypto.stackexchange.com/questions/27466/is-aes-gcm-parallelizable
  20. https://www.sciencedirect.com/science/article/pii/S2405959525000062
  21. http://mcs.csueastbay.edu/~lertaul/AESCCMCAMREADY.pdf
  22. https://docs.nvidia.com/doca/archive/2-9-0/DOCA%2BAES-GCM/index.html
  23. https://www.chelsio.com/crypto-solution/
  24. https://www.isec.tugraz.at/wp-content/uploads/teaching/mfc/ghash_Kales.pdf
  25. https://stackoverflow.com/questions/54659935/java-aes-gcm-very-slow-compared-to-aes-ctr
  26. https://datatracker.ietf.org/doc/html/rfc8446
  27. https://standards.ieee.org/ieee/802.1AE/3501/
  28. https://datatracker.ietf.org/doc/html/rfc9001
  29. https://datatracker.ietf.org/doc/html/rfc8452
  30. https://blog.cloudflare.com/pq-2024/
  31. https://www.phoronix.com/news/AES-GCM-Faster-AVX-VAES
  32. https://infotechys.com/most-efficient-openvpn-ciphers/
  33. https://eprint.iacr.org/2012/438
  34. https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.pdf
  35. https://datatracker.ietf.org/doc/html/rfc5116
  36. https://eprint.iacr.org/2009/129
  37. https://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf
  38. https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
  39. https://www.inderscienceonline.com/doi/abs/10.1504/IJBDI.2020.113875
  40. https://eprint.iacr.org/2024/1111
  41. https://nvd.nist.gov/vuln/detail/CVE-2025-54887
  42. https://nap.nationalacademies.org/read/25196/chapter/6
  43. https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/proposed-modes/gcm/gcm-nist-ipr.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.