logo资料库

GCM加密模式.pdf

第1页 / 共43页
第2页 / 共43页
第3页 / 共43页
第4页 / 共43页
第5页 / 共43页
第6页 / 共43页
第7页 / 共43页
第8页 / 共43页
资料共43页,剩余部分请下载后查看
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
分享到:
收藏