]>
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated EncryptionUniversity of Haifa and Amazon Web ServicesAbba Khoushy Ave 199Haifa3498838Israelshay@math.haifa.ac.ilGoogle345 Spear StSan FranciscoCA94105USagl@google.comBar Ilan UniversityRamat Gan5290002IsraelYehuda.Lindell@biu.ac.il
General
CFRGauthenticated encryptionaeadaesgcmsivThis memo specifies two authenticated encryption algorithms that are nonce misuse-resistant - that is that they do not fail catastrophically if a nonce is repeated.The concept of "Authenticated encryption with additional data" (AEAD ) couples confidentiality and integrity in a single operation that is easier to use correctly. The most popular AEAD, AES-GCM , is seeing widespread use due to its attractive performance.However, most AEADs suffer catastrophic failures of confidentiality and/or integrity when two distinct messages are encrypted with the same nonce. While the requirements for AEADs specify that the pair of (key, nonce) shall only ever be used once, and thus prohibit this, in practice this is a worry.Nonce misuse-resistant AEADs do not suffer from this problem. For this class of AEADs, encrypting two messages with the same nonce only discloses whether the messages were equal or not. This is the minimum amount of information that a deterministic algorithm can leak in this situation.This memo specifies two nonce misuse-resistant AEADs: AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV. These AEADs are designed to be able to take advantage of existing hardware support for AES-GCM and can decrypt within 5% of the speed of AES-GCM (for multi-kilobyte messages). Encryption is, perforce, slower than AES-GCM because two passes are required. However, measurements suggest that it can still run at 2/3rds of the speed of AES-GCM.We suggest that these AEADs be considered in any situation where there is the slightest doubt about nonce uniqueness.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.The GCM-SIV construction is similar to GCM: the block cipher is used in counter mode to encrypt the plaintext and a polynomial authenticator is used to provide integrity. The authenticator in GCM-SIV is called POLYVAL.POLYVAL, like GHASH, operates in a binary field of size 2^128. The field is defined by the irreducible polynomial x^128 + x^127 + x^126 + x^121 + 1. The sum of any two elements in the field is the result of XORing them. The product of any two elements is calculated using standard (binary) polynomial multiplication followed by reduction modulo the irreducible polynomial.We define another binary operation on elements of the field: dot(a, b), where dot(a, b) = a * b * x^-128. The value of the field element x^-128 is equal to x^127 + x^124 + x^121 + x^114 + 1. The result, dot(a, b), of this multiplication is another field element.Polynomials in this field are converted to and from 128-bit strings by taking the least-significant bit of the first byte to be the coefficient of x^0, the most-significant bit of the first byte to the coefficient of x^7 and so on, until the most-significant bit of the last byte is the coefficient of x^127.POLYVAL takes a field element, H, and a series of field elements X_1, ..., X_s. Its result is S_s, where S is defined by the iteration S_0 = 0; S_j = dot(S_{j-1} + X_j, H), for j = 0..sWe note that POLYVAL(H, X_1, X_2, ...) is equal to ByteReverse(GHASH(ByteReverse(H) * x, ByteReverse(X_1), ByteReverse(X_2), ...)), where ByteReverse is a function that reverses the order of 16 bytes. See for a more detailed explanation.AES-GCM-SIV encryption takes a 16- or 32-byte key-generating key, a 96-bit nonce, and variable-length plaintext & additional data byte-strings. It outputs an authenticated ciphertext that will be 16 bytes longer than the plaintext. Both encryption and decryption are only defined on inputs that are a whole number of bytes.If the key-generating key is 16 bytes long then AES-128 is used throughout. Otherwise AES-256 is used throughout.The first step of encryption is to generate per-nonce, record-authentication and record-encryption keys. The record-authentication key is 128-bit and the record-encryption key is either 128- (for AES-128) or 256-bit (for AES-256).These keys are generated by encrypting a series of plaintext blocks that contain a 32-bit, little-endian counter followed by the nonce, and then discarding the second half of the resulting ciphertext. In the AES-128 case, 128 + 128 = 256 bits of key material need to be generated and, since encrypting each block yields 64 bits after discarding half, four blocks need to be encrypted. The counter values for these blocks are 0, 1, 2 and 3. For AES-256, six blocks are needed in total, with counter values 0 through 5 (inclusive).In pseudocode form, where ++ indicates concatenation and x[:8] indicates taking only the first eight bytes from x:Define the "length block" as a 16-byte value that is the concatenation of the 64-bit, little-endian encodings of bytelen(additional_data) * 8 and bytelen(plaintext) * 8. Pad the plaintext and additional data with zeros until they are each a multiple of 16 bytes, the AES block size. Then X_1, X_2, ... (the series of field elements that are inputs to POLYVAL) are the concatenation of the padded additional data, the padded plaintext and the length block.Calculate S_s = POLYVAL(record-authentication-key, X_1, X_2, ...). XOR the first twelve bytes of S_s with the nonce and clear the most-significant bit of the last byte. Encrypt the result with AES using the record-encryption key to produce the tag.The encrypted plaintext is produced by using AES, with the record-encryption key, in counter mode on the unpadded plaintext. The initial counter block is the tag with the most-significant bit of the last byte set to one. The counter advances by incrementing the first 32 bits interpreted as an unsigned, little-endian integer, with overflow. The result of the encryption is the encrypted plaintext (truncated to the length of the plaintext) followed by the tag.In pseudo-code form, the encryption process can be expressed as:Decryption takes a 16- or 32-byte key-generating key, a 96-bit nonce, and variable-length ciphertext & additional data byte-strings. It either fails, or outputs a plaintext that is 16 bytes shorter than the ciphertext.Firstly, the record-encryption and record-authentication keys are derived in the same manner as when encrypting.If the ciphertext is less than 16 bytes or more than 2^36 + 16 bytes, then fail. Otherwise split the input into the encrypted plaintext and a 16-byte tag. Decrypt the encrypted plaintext with the record-encryption key in counter mode, where the initial counter block is the tag with the most-significant bit of the last byte set to one. The counter advances in the same way as for encryption.Pad the additional data and plaintext with zeros until they are each a multiple of 16 bytes, the AES block size. Calculate the length block and X_1, X_2, ... as above and compute S_s = POLYVAL(record-authentication-key, X_1, X_2, ...). Compute the expected tag by XORing S_s and the nonce, clearing the most-significant bit of the last byte and encrypting with the record-encryption key. Compare the provided and expected tag values in constant time. If they do not match, fail. Otherwise return the plaintext.In pseudo-code form, the encryption process can be expressed as:We define two AEADs, in the format of RFC 5116, that use AES-GCM-SIV: AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV. They differ only in the size of the AES key used.The key input to these AEADs becomes the key-generating key. Thus AEAD_AES_128_GCM_SIV takes a 16-byte key and AEAD_AES_256_GCM_SIV takes a 32-byte key.The parameters for AEAD_AES_128_GCM_SIV are then: K_LEN is 16, P_MAX is 2^36, A_MAX is 2^36, N_MIN and N_MAX are 12 and C_MAX is 2^36 + 16.The parameters for AEAD_AES_256_GCM_SIV differ only in the key size: K_LEN is 32, P_MAX is 2^36, A_MAX is 2^32 - 1, N_MIN and N_MAX are 12 and C_MAX is 2^36 + 16.Polynomials in this document will be written as 16-byte values. For example, the sixteen bytes 01000000000000000000000000000492 would represent the polynomial x^127 + x^124 + x^121 + x^114 + 1, which is also the value of x^-128 in this field.If a = 66e94bd4ef8a2c3b884cfa59ca342b2e and b = ff000000000000000000000000000000 then a + b = 99e94bd4ef8a2c3b884cfa59ca342b2e, a * b = 37856175e9dc9df26ebc6d6171aa0ae9 and dot(a, b) = ebe563401e7e91ea3ad6426b8140c394.Consider the encryption of the plaintext "Hello world" with the additional data "example" under key ee8e1ed9ff2540ae8f2ba9f50bc2f27c using AEAD_AES_128_GCM_SIV. The random nonce that we'll use for this example is 752abad3e0afb5f434dc4310.In order to generate the record-authentication and record-encryption keys, a counter is combined with the nonce to form four blocks. These blocks are encrypted with key given above:The latter halves of the ciphertext blocks are discarded and the remaining bytes are concatenated to form the per-record keys. Thus the record-authentication key is 310728d9911f1f3837b24316c3fab9a0 and the record-encryption key is a4c5ae6249963279c100be4d7e2c6edd.The length block contains the encoding of the bit-lengths of the additional data and plaintext, respectively. The string "example" is seven characters, thus 56 bits (or 0x38 in hex). The string "Hello world" is 11 characters, or 88 = 0x58 bits. Thus the length block is 38000000000000005800000000000000.The input to POLYVAL is the padded additional data, padded plaintext and then the length block. This is 6578616d706c6500000000000000000048656c6c6f20776f726c64000000000038000000000000005800000000000000, based on the ASCII encoding of "example" (6578616d706c65) and of "Hello world" (48656c6c6f20776f726c64).Calling POLYVAL with the record-authentication key and the input above results in S_s = ad7fcf0b5169851662672f3c5f95138f.Before encrypting, the nonce is XORed in and the most-significant bit of the last byte is cleared. This gives d85575d8b1c630e256bb6c2c5f95130f because that bit happened to be one previously. Encrypting with the record-encryption key gives the tag, which is 4fbcdeb7e4793f4a1d7e4faa70100af1.In order to form the initial counter block, the most-significant bit of the last byte of the tag is set to one. That doesn't result in a change in this example. Encrypting this with the record key gives the first block of the keystream: 1551f2c1787e81deac9a99f139540ab5.The final ciphertext is the result of XORing the plaintext with the keystream and appending the tag. That gives 5d349ead175ef6b1def6fd4fbcdeb7e4793f4a1d7e4faa70100af1.A detailed analysis of these schemes appears in and the remainder of this section is a summary of that paper.The AEADs defined in this document calculate fresh AES keys for each nonce. This allows a larger number of plaintexts to be encrypted under a given key. Without this step, each SIV encryption would be like a standard GCM encryption with a random nonce. Since the nonce size for GCM is only 12 bytes, NIST set a limit of 2^32 encryptions before the probability of duplicate nonces becomes too high.The authors felt that, while large, 2^32 wasn't so large that this limit could be safely ignored. For example, consider encrypting the contents of a hard disk where the AEAD record size is 512 bytes, to match the traditional size of a disk sector. This process would have encrypted 2^32 records after processing 2TB, yet hard drives of multiple terabytes are now common.Deriving fresh AES keys for each nonce alleviates this problem.If the nonce is fixed then AES-GCM-SIV acts like AES-GCM with a random nonce, with the caveat that identical plaintexts will produce identical ciphertexts. However, we feel that the 2^32 limit for AES-GCM is too risky in a multi-key setting. Thus with AES-GCM-SIV we recommend that, for a specific key, a nonce not be repeated more than 2^8 times. (And, ideally, not be repeated at all.) For up to 256 repeats of a nonce, the following message limits should be respected (this assumes a short AAD):2^29 messages, where each plaintext is at most 1GiB2^35 messages, where each plaintext is at most 128MiB2^49 messages, where each plaintext is at most 1MiB2^61 messages, where each plaintext is at most 16KiBSuzuki et al show that even if nonces are selected uniformly at random, the probability that one or more values would be repeated 256 or more times is negligible until the number of nonces reaches 2^102. (Specifically the probability is 1/((2^96)^(255)) * Binomial(q, 256), where q is the number of nonces.) Since 2^102 is vastly greater than the limit on the number of plaintexts per key given above, we don't feel that this limit on the number of repeated nonces will be a problem. This also means that selecting nonces at random is a safe practice with AES-GCM-SIV.For situations where, for some reason, an even higher number of nonce repeats is possible (e.g. in devices with very poor randomness), the message limits need to be reconsidered. Theorem seven in the paper contains more details but, for up to 1,024 repeats of each nonce, the limits would be (again assuming a short AAD):2^25 messages, where each plaintext is at most 1GiB2^31 messages, where each plaintext is at most 128MiB2^45 messages, where each plaintext is at most 1MiB2^57 messages, where each plaintext is at most 16KiBIn addition to calculating fresh AES keys for each nonce, these AEADs also calculate fresh POLYVAL keys. Previous versions of GCM-SIV did not do this and, instead, used part of the AEAD's key as the POLYVAL key. Bleichenbacher pointed out that this allowed an attacker who controlled the AEAD key to force the POLYVAL key to be zero. If a user of this AEAD authenticated messages with a secret additional-data value then this would be insecure as the attacker could calculate a valid authenticator without knowing the input. This does not violate the standard properties of an AEAD as the additional data is not assumed to be confidential. However, we want these AEADs to be robust to plausible misuse and also to be drop-in replacements for AES-GCM and so derive nonce-specific POLYVAL keys to avoid this issue.We also wish to note that the probability of successful forgery increases with the number of attempts that an attacker is permitted. If an attacker is permitted extremely large numbers of attempts then the tiny probability that any given attempt succeeds may sum to a non-trivial chance.A security analysis of a similar scheme appears in .IANA is requested to add two entries to the registry of AEAD algorithms: AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV, both referencing this document as their specification.The authors would like to thank Uri Blumenthal, Ondrej Mosnacek, Daniel Bleichenbacher, Kenny Paterson, Bart Preneel, John Mattsson, Scott Fluhrer, Tibor Jager, Bjoern Tackmann, Yannick Seurin, Tetsu Iwata and Deb Cooley's team at NSA Information Assurance for their helpful suggestions and review.
&RFC2119;
&RFC5116;
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
AES-GCM-SIV: specification and analysis
GCM-SIV: Full Nonce Misuse-Resistant Authenticated Encryption at Under One Cycle Per Byte
Birthday Paradox for Multi-collisions
GHASH and POLYVAL both operate in GF(2^128), although with different irreducible polynomials: POLYVAL works modulo x^128 + x^127 + x^126 + x^121 + 1 and GHASH works modulo x^128 + x^7 + x^2 + x + 1. Note that these irreducible polynomials are the "reverse" of each other.GHASH also has a different mapping between 128-bit strings and field elements. Where as POLYVAL takes the least-significant to most-significant bits of the first byte to be the coefficients of x^0 to x^7, GHASH takes them to be the coefficients of x^7 to x^0. This continues until, for the last byte, POLYVAL takes the least-significant to most-significant bits to be the coefficients of x^120 to x^127 while GHASH takes them to be the coefficients of x^127 to x^120.The combination of these facts means that it's possible to "convert" values between the two by reversing the order of the bytes in a 16-byte string. The differing interpretations of bit order takes care of reversing the bits within each byte and then reversing the bytes does the rest. This may have a practical benefit for implementations that wish to implement both GHASH and POLYVAL.In order to be clear which field a given operation is performed in, let mulX_GHASH be a function that takes a 16-byte string, converts it to an element of GHASH's field using GHASH's convention, multiplies it by x and converts back to a string. Likewise, let mulX_POLYVAL be a function that converts a 16-byte string to an element of POLYVAL's field using POLYVAL's convention, multiplies it by x and converts back.Given the 16-byte string 01000000000000000000000000000000, mulX_GHASH of that string is 00800000000000000000000000000000 and mulX_POLYVAL of that string is 02000000000000000000000000000000. As a more general example, given 9c98c04df9387ded828175a92ba652d8, mulX_GHASH of that string is 4e4c6026fc9c3ef6c140bad495d3296c and mulX_POLYVAL of it is 3931819bf271fada0503eb52574ca5f2.Lastly, let ByteReverse be the function that takes a 16-byte string and returns a copy where the order of the bytes has been reversed.Now GHASH and POLYVAL can be defined in terms of one another:POLYVAL(H, X_1, ..., X_n) = ByteReverse(GHASH(mulX_GHASH(ByteReverse(H)), ByteReverse(X_1), ..., ByteReverse(X_n)))GHASH(H, X_1, ..., X_n) = ByteReverse(POLYVAL(mulX_POLYVAL(ByteReverse(H)), ByteReverse(X_1), ..., ByteReverse(X_n)))As a worked example, let H = 25629347589242761d31f826ba4b757b, X_1 = 4f4f95668c83dfb6401762bb2d01a262 and X_2 = d1a24ddd2721d006bbe45f20d3c9f362. POLYVAL(H, X_1, X_2) = f7a3b47b846119fae5b7866cf5e5b77e. If we wished to calculate this given only an implementation of GHASH then the key for GHASH would be mulX_GHASH(ByteReverse(H)) = dcbaa5dd137c188ebb21492c23c9b112. Then ByteReverse(GHASH(dcba..., ByteReverse(X_1), ByteReverse(X_2))) = f7a3b47b846119fae5b7866cf5e5b77e, as required.In the other direction, GHASH(H, X_1, X_2) = bd9b3997046731fb96251b91f9c99d7a. If we wished to calculate this given only an implementation of POLYVAL then we would first calculate the key for POLYVAL, mulX_POLYVAL(ByteReverse(H)), which is f6ea96744df0633aec8424b18e26c54a. Then ByteReverse(POLYVAL(f6ea..., ByteReverse(X_1), ByteReverse(X_2))) = bd9b3997046731fb96251b91f9c99d7a.Some, non-security, properties also differ between AES-GCM and AES-GCM-SIV that are worth noting:AES-GCM allows plaintexts to be encrypted in a streaming fashion, i.e. the beginning of the plaintext can be encrypted and transmitted before the entire message has been processed. AES-GCM-SIV requires two passes for encryption and so cannot do this.AES-GCM allows a constant additional-data input to be precomputed in order to save per-record computation. AES-GCM-SIV varies the authenticator key based on the nonce and so does not permit this.The performance for AES-GCM vs AES-GCM-SIV on small machines can be roughly characterised by the number of AES operations and the number of GF(2^128) multiplications needed to process a message. Let a = (bytelen(additional-data) + 15) / 16 and p = (bytelen(plaintext) + 15) / 16. Then AES-GCM requires p + 1 AES operations and p + a + 1 field multiplications.Defined similarly, AES-GCM-SIV with AES-128 requires p + 5 AES operations and p + a + 1 field multiplications. With AES-256 that becomes p + 7 AES operations.With large machines, the available parallelism becomes far more important and such simple performance analysis is no longer representative. For such machines, we find that decryption of AES-GCM-SIV is only about 5% slower then AES-GCM, as long as the message is at least a couple of kilobytes. Encryption tends to be about 2/3's the speed because of the additional pass required.The tests in this section use AEAD_AES_256_GCM_SIV and are crafted to test correct wrapping of the block counter.