As the need for gigabit data increases over time, there is a 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 method must admit pipelined and parallelized implementations and have minimal computational latency in order to be useful at high data rates. Counter mode is one of the best methods out there for high-speed encryption.

Counter mode provides high speed encryption but there was a lack of method to provide message authentication that could keep up with the encryption cipher. This was crucial since counter mode does not provide protection against bit-flipping attacks.

GCM fulfills this need. CBC-MAC, and the modes that use it to provide authentication, such as CCM, EAX and OMAC, cannot be pipelined or parallelized and thus are unsuitable for high data rates. OCB is covered by intellectual property claims. CWC’s message authentication component is less suitable for high speed implementations.

Inputs and Outputs to GCM

GCM has two operations, authenticated encryption and authenticated decryption. The authenticated encryption operation has four inputs, each of which is a bit string:

The There two Outputs

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 with the encrypt operation with inputs K, IV, A and P, for some plaintext P. The authenticated decrypt operation will, with high probability, return ‘FAIL’ when 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 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, its desirable to authenticate these fields, though they must be left in the clear for the network 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 is highly likely. The IV is authenticated, and it is not necessary to include it in 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.

The two main functions used in GCM are block cipher encryption and multiplication over the field GF(2^128). The block cipher encryption of the value X with the key K is denoted as E(K,Y). The multiplication of the two elements X,Y ∈ GF(2^128) is denoted as X·Y, and addition of X and Y is denoted as X⊕Y.

The function len ( ) returns a 64-bit string containing the non-negative describing the number of bits in its argument, with the least significant bit on the right. The expression 0^l denotes a string of ‘l’ zero bits, and A ll B 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 a bit string of length zero.

Let ’n’ and ‘u’ denote 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 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 …. P(n-1), Pn, and the bit strings are called data block, although the last bit string, Pn, may not be a complete block. Similarly the ciphertext is denoted as C1, C2…. C(n-1), Cn, where the number of bits in the final block Cn is u. The additional authenticated data A is denoted as A1, A2…. A(m-1), Am, where the last bit string Am maybe 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.

The authenticated encryption operation is defined by the following equations:

The authenticated encryption operation

For simplicity, a case with only a single block 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(2^128) by the hash key H, and incr denotes the counter increment function.

The authenticated decryption operation is similar to the encrypt operation, but with the order of the hash step and encrypt step reversed. The equations are as follows:

The authenticated decryption operation

Implementing GCM is straightforward both in both hardware and software given an implementation of the underlying block cipher and the multiplication operation over GF(2^128).

The number of block cipher invocations needed to encrypt a p-bit plaintext with AES GCM is equal to [p/128] + 1. The same number of multiplications over GF(2^128) are needed. An additional block cipher invocation is needed to compute the hash key H if it is not stored. If there are additional q bits of data to be authenticated, then an additional [q/128] multiplications are needed. The decrypt operation is similar to the encrypt operation and shares its performance characteristics.

A Data filed is encrypted and authenticated, and is carried along with a header and a sequence number. The header is authenticated by including it in the AAD. The sequence number is included in the IV. The authentication tag is carried along with the encrypted data in an Integrity Check Value (ICV). There is no need to pad the plaintext, since any length can be provided as an input. In the authentication decrypt operation these fields provide the inputs. The plaintext is the output, unless the authentication check failed. In that case the decrypt operation would return ‘FAIL’ than the plaintext, and the decapsulation would halt and the plaintext would be discarded rather than forwarded or further processed. After the operation, the header and sequence number can be checked, and their values can be trusted.

By including the sequence number in the IV, we can satisfy the requirement that IV values can be unique. If that number is less than 96 bits longs, it can be concatenated with another value in order to form the IV. This other value could be a constant, like a string of zeros, or it could be a random string, which adds to the security of the system because it makes the inputs less predictable than they would be otherwise. The data needed to form the IV has to be known to both the encrypt side and decrypt side, but it need not all be included in the packet.

In some situations it maybe desirable to have the same GCM key used for encryption by more than one device. In this case, coordination is needed to ensure uniqueness of the IV values. A simple way in which this requirement can be met is to include a device specific value in the IV, such as network address.

Figure: Using GCM to encrypt and authenticate a packet, showing how the fields of the security encapsulation map onto the inputs and outputs of the authenticated encryption mode.

Figure: Using GCM to decrypt and verify the authenticity of a packet