The Galois/Counter Mode of Operation (GCM)
David A. McGrew
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95032
mcgrew@cisco.com
John Viega
Secure Software
4100 Lafayette Center Drive, Suite 100
Chantilly, VA 20151
viega@securesoftware.com
Contents
1
Introduction
2 Definition
2.1
Inputs and Outputs .
2.2 Notation .
.
2.3 Encryption .
2.4 Decryption .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Multiplication in GF (2128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 The Field GF (2128)
4
Implementation
1
2
2
3
4
7
7
8
10
4.1
Software .
.
4.2 Hardware .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Using GCM
6 Properties and Rationale
7 Security
A GCM for 64-bit block ciphers
B AES Test Vectors
15
16
22
25
27
GCM
1
Introduction
Galois/Counter Mode (GCM) is a block cipher mode of operation that uses universal hashing over
a binary Galois field to provide authenticated encryption. It can be implemented in hardware to
achieve high speeds with low cost and low latency. Software implementations can achieve excel-
lent performance by using table-driven field operations. It uses mechanisms that are supported
by a well-understood theoretical foundation, and its security follows from a single reasonable
assumption about the security of the block cipher.
There is a compelling need for a mode of operation that can efficiently provide authenticated
encryption at speeds of 10 gigabits per second and above in hardware, perform well in software,
and is free of intellectual property restrictions. The mode must admit pipelined and paralellized
implementations and have minimal computational latency in order to be useful at high data rates.
Counter mode has emerged as the best method for high-speed encryption, because it meets those
requirements. However, there is no suitable standard message authentication algorithm. This fact
leaves us in the situation in which we can encrypt at high speed, but we cannot provide message
authentication that can keep up with our cipher. This lack is especially conspicuous since counter
mode provides no protection against bit-flipping attacks.
GCM fills this need, while no other proposed mode meets the same criteria. CBC-MAC [1, Ap-
pendix F] and the modes that use it to provide authentication, such as CCM [2], EAX [3], and
OMAC [4], cannot be pipelined or parallelized, and thus are unsuitable for high data rates. OCB
[5] is covered by multiple intellectual property claims. CWC [6] does not share those problems,
but is less appropriate for high speed implementations. In particular, CWC’s message authen-
tication component uses 127-bit integer multiplication operations whose implementation costs
exceed those of even AES counter mode at high speeds, and it has a circuit depth that is twice
that of GCM. In contrast, the binary field multiplication used to provide authentication in GCM is
easily implemented at a fraction of the cost of counter mode at high speeds.
GCM also has additional useful properties. It is capable of acting as a stand-alone MAC, authen-
ticating messages when there is no data to encrypt, with no modifications. Importantly, it can be
used as an incremental MAC [7]: if an authentication tag is computed for a message, then part of
the message is changed, an authentication tag can be computed for the new message with compu-
tational cost proportional to the number of bits that were changed. This feature is unique among
all of the proposed modes.
Another useful property is that it accepts initialization vectors of arbitrary length, which makes it
easier for applications to meet the requirement that all IVs be distinct. In many situations in which
authenticated encryption is needed, there is a data element that could be used as a nonce, or as a
part of a nonce, except that the length of the element(s) may exceed the block size of the cipher. In
GCM, a nonce of any size can be used as the IV. This property is shared with EAX, but no other
1
GCM
proposed mode.
This document is organized as follows. Section 2 contains a complete specification of GCM, and
is the only normative part of this document. Section 3 contains an overview of finite fields and
a detailed description of the field representation used in GCM. Implementation strategies are de-
scribed in Section 4, along with a discussion of their performance. A summary of the mode’s
properties and a rationale for its design is offered in Section 6, along with a detailed performance
comparison with other modes. The security analysis is summarized in Section 7. Appendix A
describes the use of GCM for 64-bit block ciphers. Test data that can be used for validating AES
GCM implementations is contained in Appendix B.
2 Definition
This section contains the complete definition of GCM for 128-bit block ciphers. The mode is
slightly different when applied to 64-bit block ciphers; those differences are outlined in Appendix A.
2.1 Inputs and Outputs
GCM has two operations, authenticated encryption and authenticated decryption. The authenti-
cated encryption operation has four inputs, each of which is a bit string:
• A secret key K, whose length is appropriate for the underlying block cipher.
• An initialization vector IV , that can have any number of bits between 1 and 264. For a fixed
value of the key, each IV value must be distinct, but need not have equal lengths. 96-bit
IV values can be processed more efficiently, so that length is recommended for situations in
which efficiency is critical.
• A plaintext P , which can have any number of bits between 0 and 239 − 256.
• Additional authenticated data (AAD), which is denoted as A. This data is authenticated, but
not encrypted, and can have any number of bits between 0 and 264.
There are two outputs:
• A ciphertext C whose length is exactly that of the plaintext P .
2
GCM
2.2 Notation
• An authentication tag T , whose length can be any value between 0 and 128. The length of
the tag is denoted as t.
The authenticated decryption operation has five inputs: K, IV , C, A, and T . It has only a single
output, either the plaintext value P or a special symbol FAIL that indicates that the inputs are not
authentic. A ciphertext C, initialization vector IV , additional authenticated data A and tag T are
authentic for key K when they are generated by the encrypt operation with inputs K, IV , A and
P , for some plaintext P . The authenticated decrypt operation will, with high probability, return
FAIL whenever its inputs were not created by the encrypt operation with the identical key.
The additional authenticated data A is used to protect information that needs to be authenticated,
but which must be left unencrypted. When using GCM to secure a network protocol, this input
could include addresses, ports, sequence numbers, protocol version numbers, and other fields that
indicate how the plaintext should be handled, forwarded, or processed. In many situations, it is
desirable to authenticate these fields, though they must be left in the clear to allow the network or
system to function properly. When this data is included in the AAD, authentication is provided
without copying the data into the ciphertext.
The primary purpose of the IV is to be a nonce, that is, to be distinct for each invocation of the
encryption operation for a fixed key. It is acceptable for the IV to be generated randomly, as long
as the distinctness of the IV values is highly likely. The IV is authenticated, and it is not necessary
to include it in the AAD field.
Both confidentiality and message authentication is provided on the plaintext. The strength of the
authentication of P, IV and A is determined by the length t of the authentication tag. When the
length of P is zero, GCM acts as a MAC on the input A. The mode of operation that uses GCM as
a stand-alone message authentication code is denoted as GMAC.
An example use of GCM for network security is provided in Section 5, which shows how the
inputs and outputs can be used in a typical cryptographic application.
2.2 Notation
Our notation follows that of the Recommendation for Block Cipher Modes of Operation [8]. The
two main functions used in GCM are block cipher encryption and multiplication over the field
GF (2128). The block cipher encryption of the value X with the key K is denoted as E(K, X). The
multiplication of two elements X, Y ∈ GF (2128) is denoted as X · Y , and the addition of X and Y
is denoted as X ⊕ Y . Addition in this field is equivalent to the bitwise exclusive-or operation, and
the multiplication operation is defined in Section 2.5.
3
GCM
2.3 Encryption
The function len() returns a 64-bit string containing the nonnegative integer describing the num-
ber of bits in its argument, with the least significant bit on the right. The expression 0l denotes a
string of l zero bits, and AkB denotes the concatenation of two bit strings A and B. The function
MSBt(S) returns the bit string containing only the most significant (leftmost) t bits of S, and the
symbol {} denotes the bit string with zero length.
2.3 Encryption
Let n and u denote the unique pair of positive integers such that the total number of bits in the
plaintext is (n − 1)128 + u, where 1 ≤ u ≤ 128. The plaintext consists of a sequence of n bit
strings, in which the bit length of the last bit string is u, and the bit length of the other bit strings
is 128. The sequence is denoted P1, P2, . . . , Pn−1, P ∗
n , and the bit strings are called data blocks,
although the last bit string, P ∗
n , may not be a complete block. Similarly, the ciphertext is denoted
as C1, C2, . . . , Cn−1, C∗
n is u. The additional au-
thenticated data A is denoted as A1, A2, . . . , Am−1, A∗
m may be a
partial block of length v, and m and v denote the unique pair of positive integers such that the
total number of bits in A is (m − 1)128 + v and 1 ≤ v ≤ 128.
n, where the number of bits in the final block C∗
m , where the last bit string A∗
The authenticated encryption operation is defined by the following equations:
(
H = E(K, 0128)
IV k0311
GHASH(H,{}, IV )
Y0 =
if len(IV ) = 96
otherwise.
Yi = incr(Yi−1) for i = 1, . . . , n
Ci = Pi ⊕ E(K, Yi) for i = 1, . . . , n − 1
C∗
n = P ∗
T = MSBt(GHASH(H, A, C) ⊕ E(K, Y0))
n ⊕ MSBu(E(K, Yn))
(1)
Successive counter values are generated using the function incr(), which treats the rightmost 32
bits of its argument as a nonnegative integer with the least significant bit on the right, and incre-
ments this value modulo 232. More formally, the value of incr(FkI) is Fk(I + 1 mod 232). The
encryption process is illustrated in Figure 1.
The function GHASH is defined by GHASH(H, A, C) = Xm+n+1, where the inputs A and C are
4
GCM
2.3 Encryption
Figure 1: The authenticated encryption 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. Here EK
denotes the block cipher encryption using the key K, multH denotes multiplication in GF (2128)
by the hash key H, and incr denotes the counter increment function.
5
ECounter 1Plaintext 1Ciphertext 1ECounter 2Plaintext 2Ciphertext 2incrKKmultHmultHAuth Data 1multHlen(A) || len(C)Auth TagmultHECounter 0incrK
GCM
2.3 Encryption
Figure 2: The authenticated decryption operation, showing the same case as in Figure 1.
6
ECounter 1Plaintext 1Ciphertext 1ECounter 2Plaintext 2Ciphertext 2incrKKmultHmultHAuth Data 1multHlen(A) || len(C)Auth TagmultHECounter 0incrK