INFORMATIONAL

Errata Exist

Internet Research Task Force (IRTF) S. Gueron Request for Comments: 8452 University of Haifa and Amazon Category: Informational A. Langley ISSN: 2070-1721 Google LLC Y. Lindell Bar-Ilan University and Unbound Tech April 2019 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption Abstract This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated. This document is the product of the Crypto Forum Research Group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8452. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gueron, et al. Informational [Page 1]

RFC 8452 AES-GCM-SIV April 2019 Section 9, it is RECOMMENDED to use this scheme with randomly chosen nonces. This document represents the consensus of the Crypto Forum Research Group (CFRG). 2 . Requirements Language BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3 . POLYVAL GCM], Section 6.4), 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 of this multiplication, dot(a, b), is another field element. Gueron, et al. Informational [Page 3]

RFC 8452 AES-GCM-SIV April 2019 SP800-38A], Section 6.5) 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 Gueron, et al. Informational [Page 5]

RFC 8452 AES-GCM-SIV April 2019 6 . AEADs 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 as follows: 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^36, N_MIN and N_MAX are 12, and C_MAX is 2^36 + 16. 7 . Field Operation Examples 8 . Worked Example Gueron, et al. Informational [Page 10]

RFC 8452 AES-GCM-SIV April 2019 AES-GCM-SIV], 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, AES-GCM-SIV encryption would be limited by the birthday bound like other standard modes (e.g., AES-GCM, AES-CCM [RFC3610], and AES-SIV [RFC5297]). This means that when 2^64 blocks have been encrypted overall, a distinguishing adversary who is trying to break the confidentiality of the scheme has an advantage of 1/2. Thus, in order to limit the adversary's advantage to 2^-32, at most 2^48 blocks can be encrypted overall. In contrast, by deriving fresh keys from each nonce, it is possible to encrypt a far larger number of messages and blocks with AES-GCM-SIV. We stress that nonce misuse-resistant schemes guarantee that if a nonce repeats, then the only security loss is that identical plaintexts will produce identical ciphertexts. Since this can also be a concern (as the fact that the same plaintext has been encrypted twice is revealed), we do not recommend using a fixed nonce as a policy. In addition, as we show below, better-than-birthday bounds are achieved by AES-GCM-SIV when the nonce repetition rate is low. Finally, as shown in [BHT18], there is a great security benefit in the multiuser/multikey setting when each particular nonce is reused by a small number of users only. We stress that the nonce misuse- resistance property is not intended to be coupled with intentional nonce reuse; rather, such schemes provide the best possible security in the event of nonce reuse. Due to all of the above, it is RECOMMENDED that AES-GCM-SIV nonces be randomly generated. Some example usage bounds for AES-GCM-SIV are given below. The adversary's advantage is the "AdvEnc" from [key-derive] and is colloquially the ability of an attacker to distinguish ciphertexts from random bit strings. The bounds below limit this advantage to 2^-32. For up to 256 uses of the same nonce and key (i.e., where one can assume that nonce misuse is no more than this bound), the following message limits should be respected (this assumes a short additional authenticated data (AAD), i.e., less than 64 bytes): 2^29 messages, where each plaintext is at most 1 GiB 2^35 messages, where each plaintext is at most 128 MiB Gueron, et al. Informational [Page 12]

RFC 8452 AES-GCM-SIV April 2019 multi-birthday] 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. The bounds obtained for random nonces are as follows (as above, for these bounds, the adversary's advantage is at most 2^-32): 2^32 messages, where each plaintext is at most 8 GiB 2^48 messages, where each plaintext is at most 32 MiB 2^64 messages, where each plaintext is at most 128 KiB 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 7 in [AES-GCM-SIV] contains more details, but for up to 1,024 repeats of each nonce, the limits would be (again assuming a short AAD, i.e., less than 64 bytes): 2^25 messages, where each plaintext is at most 1 GiB 2^31 messages, where each plaintext is at most 128 MiB 2^45 messages, where each plaintext is at most 1 MiB 2^57 messages, where each plaintext is at most 16 KiB In 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 [Bleichenbacher16] 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 Gueron, et al. Informational [Page 13]

RFC 8452 AES-GCM-SIV April 2019 key-derive] and used above is specified in terms of the ability of an attacker to distinguish ciphertexts from random bit strings. It thus covers both confidentiality and integrity, and Theorem 6.2 in [key-derive] shows that the advantage increases with the number of decryption attempts, although much more slowly than with the number of encryptions; the dependence on the number of decryption queries for forgery is actually only linear, not quadratic. The latter is an artifact of the bound in the paper not being tight. 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 without nonce-based key derivation appears in [GCM-SIV], and a full analysis of the bounds when applying nonce-based key derivation appears in [key-derive]. A larger table of bounds and other information appears at [aes-gcm-siv-homepage]. The multiuser/multikey security of AES-GCM-SIV was studied by [BHT18], which showed that security is almost the same as in the single-user setting, as long as nonces do not repeat many times across many users. This is the case when nonces are chosen randomly. 10 . IANA Considerations 11 . References 11.1 . Normative References RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. Gueron, et al. Informational [Page 14]