Galois Counter Mode with Secure Short Tags (GCM-SST)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 June 2025.¶

Copyright Notice

Copyright (c) 2024 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.¶

Table of Contents

1. Introduction

Advanced Encryption Standard (AES) in Galois Counter Mode (AES-GCM) [GCM] is a widely used AEAD algorithm [RFC5116] due to its attractive performance in both software and hardware as well as its provable security. During the NIST standardization, Ferguson pointed out two weaknesses in the GCM authentication function [Ferguson], particularly problematic when short tags are used. The first weakness significantly increases the probability of successful forgery. The second weakness reveals the subkey H if an attacker succeeds in creating forgeries. Once H is known, the attacker can consistently forge subsequent messages, drastically increasing the probability of multiple successful forgeries.¶

In a comment to NIST, Nyberg et al. [Nyberg] explained how small changes based on proven theoretical constructions mitigate these weaknesses. Unfortunately, NIST did not follow the advice from Nyberg et al. and instead specified additional requirements for use with short tags in Appendix C of [GCM]. NIST did not give any motivations for the parameter choices or the assumed security levels. Mattsson et al. [Mattsson] later demonstrated that attackers can almost always obtain feedback on the success or failure of forgery attempts, contradicting the assumptions NIST made for short tags. Furthermore, NIST appears to have relied on non-optimal attacks when calculating the parameters. Rogaway [Rogaway] criticizes the use of GCM with short tags and recommends prohibiting tags shorter than 96 bits. Reflecting the critique, NIST is planning to remove support for GCM with tags shorter than 96 bits [Revise]. While Counter with CBC-MAC (CCM) [RFC5116] with short tags has forgery probabilities close to ideal, its performance is lower than that of GCM.¶

Short tags are widely used, 32-bit tags are standard in most radio link layers including 5G [Sec5G], 64-bit tags are very common in transport and application layers of the Internet of Things, and 32-, 64-, and 80-bit tags are common in media-encryption applications. Audio packets are small, numerous, and ephemeral. As such, they are highly sensitive to cryptographic overhead, but forgery of individual packets is not a big concern as it typically is barely noticeable as each packet often only encodes 20 ms of audio. Due to its weaknesses, GCM is typically not used with short tags. The result is either decreased performance from larger than needed tags [MoQ], or decreased performance from using much slower constructions such as AES-CTR combined with HMAC [RFC3711][RFC9605]. Short tags are also useful to protect packets whose payloads are secured at higher layers, protocols where the security is given by the sum of the tag lengths, and in constrained radio networks, where the low bandwidth preclude many repeated trial. For all applications of short tags it is essential that the MAC behaves like an ideal MAC, i.e., the forgery probability is ≈ 2^-tag_length even after many generated MACs, many forgery attempts, and after a successful forgery. For a comprehensive discussion on the use cases and requirements of short tags, see [Comments38B].¶

This document defines the Galois Counter Mode with Secure Short Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm following the recommendations from Nyberg et al. [Nyberg] and Inoue et al. [Inoue]. GCM-SST is defined with a general interface, allowing it to be used with any keystream generator, not just 128-bit block ciphers. The main differences from GCM [GCM] are the introduction of an additional subkey Q, the derivation of fresh subkeys H and Q for each nonce, and the replacement of the GHASH function with the POLYVAL function from AES-GCM-SIV [RFC8452], and the replacement of masking with injective non-zero padding, see Section 3. These changes enable truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, see Section 5. GCM-SST is designed for use in unicast security protocols with replay protection, where its authentication tag behaves like an ideal MAC. Its performance is similar to GCM [GCM], with the additional AES invocation compensated by the use of POLYVAL, the ”little-endian version” of GHASH, which is faster on little-endian architectures. GCM-SST retains the additive encryption characteristic of GCM, which enables efficient implementations on modern processor architectures, see [Gueron] and Section 2.4 of [GCM-Update].¶

This document also registers several GCM-SST instances using Advanced Encryption Standard (AES) [AES] and Rijndael with 256-bit keys and blocks (Rijndael-256-256) [Rijndael] in counter mode as keystream generators and with tag lengths of 32, 64, 96, and 112 bits, see Section 4. The authentication tags in all registered GCM-SST instances behave like ideal MACs, which is not the case at all for GCM [GCM]. 3GPP has standardized the use of Rijndael-256-256 for authentication and key generation in 3GPP TS 35.234–35.237 [WID23]. NIST is anticipated to standardize Rijndael-256-256 [Options], although there may be revisions to the key schedule.¶

GCM-SST was originally developed by ETSI SAGE, under the name Mac5G, following a request from 3GPP, with several years of discussion and refinement contributing to its design [SAGE23][SAGE24]. Mac5G is constructed similarly to the integrity algorithms used for SNOW 3G [UIA2] and ZUC [EIA3]. 3GPP has decided to standardize Mac5G for use with AES-256 [AES], SNOW 5G [SNOW], and ZUC-256 [ZUC] in 3GPP TS 35.240–35.248 [WID24]. GCM-SST is an evolution of Mac5G incorporating the ideas proposed by Inoue et al. [Inoue].¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following notation is used in the document:¶

• K is the key as defined in [RFC5116]¶

• N is the nonce as defined in [RFC5116]¶

• A is the associated data as defined in [RFC5116]¶

• P is the plaintext as defined in [RFC5116]¶

• Z is the keystream¶

• ct is the ciphertext¶

• tag is the authentication tag¶

• = is the assignment operator¶

• != is the inequality operator¶

• x || y is concatenation of the octet strings x and y¶

• XOR is the bitwise exclusive OR operator¶

• 0x is a prefix used to denote hexadecimal numbers¶

• len(x) is the length of x in bits.¶

• zeropad(x) right pads an octet string x with zeroes to a multiple of 128 bits¶

• truncate(x, t) is the truncation operation. The first t bits of x are kept¶

• n is the number of 128-bit chunks in zeropad(ct || 0x80)¶

• m is the number of 128-bit chunks in zeropad(A)¶

• POLYVAL is defined in [RFC8452]¶

• BE32(x) is the big-endian encoding of 32-bit integer x¶

• LE64(x) is the little-endian encoding of 64-bit integer x¶

• V[y] is the 128-bit chunk with index y in the array V; the first chunk has index 0.¶

• V[x:y] are the range of chunks x to y in the array V¶

3. Galois Counter Mode with Secure Short Tags (GCM-SST)

This section defines the Galois Counter Mode with Secure Short Tags (GCM-SST) AEAD algorithm following the recommendations from Nyberg et al. [Nyberg] and Inoue et al. [Inoue]. GCM-SST is defined with a general interface so that it can be used with any keystream generator, not just a 128-bit block cipher.¶

GCM-SST adheres to an AEAD interface [RFC5116] and the encryption function takes four variable-length octet string parameters. A secret key K, a nonce N, the associated data A, and a plaintext P. The keystream generator is instantiated with K and N. The keystream MAY depend on P and A. The minimum and maximum lengths of all parameters depend on the keystream generator. The keystream generator produces a keystream Z consisting of 128-bit chunks where the first two chunks Z[0] and Z[1] are used as the two subkeys H and Q. The following keystream chunks Z[2], Z[3], ..., Z[n + 1] are used to encrypt the plaintext. Instead of GHASH [GCM], GCM-SST makes use of the POLYVAL function from AES-GCM-SIV [RFC8452], which results in more efficient software implementations on little-endian architectures. GHASH and POLYVAL can be defined in terms of one another [RFC8452]. The subkeys H and Q are field elements used in POLYVAL. As the subkeys H and Q are nonce-dependent, the masking can be replaced by an injective non-zero padding of the ciphertext [Inoue]. Both encryption and decryption are only defined on inputs that are a whole number of octets.¶

4. AES and Rijndael-256-256 in GCM-SST

This section defines Advanced Encryption Standard (AES) and Rijndael with 256-bit keys and blocks (Rijndael-256-256) [Rijndael] in Galois Counter Mode with Secure Short Tags.¶

5. Security Considerations

GCM-SST introduces an additional subkey Q, alongside the subkey H. The inclusion of Q enables truncated tags with forgery probabilities close to ideal. Both Q and H are derived for each nonce, which significantly decreases the probability of multiple successful forgeries. These changes are based on proven theoretical constructions and follows the recommendations in [Nyberg]. Inoue et al. [Inoue] prove that GCM-SST is a provably secure authenticated encryption mode, with security guaranteed for evaluations under fresh nonces, even if some earlier nonces have been reused.¶

GCM-SST is designed for use in unicast security protocols with replay protection. Every key MUST be randomly chosen from a uniform distribution. GCM-SST MUST be used in a nonce-respecting setting: for a given key, a nonce MUST only be used once in the encryption function and only once in a successful decryption function call. The nonce MAY be public or predictable. It can be a counter, the output of a permutation, or a generator with a long period. GCM-SST MUST NOT be used with random nonces [Collision] and MUST be used with replay protection. GCM-SST MUST NOT be used in multicast or broadcast. Reuse of nonces in the encryption function and the decryption function enable universal forgery Lindell [Inoue]. It is important to note that GCM allows universal forgery with lower complexity than GCM-SST, even when nonces are not reused. Implementations MAY add randomness to the nonce by XORing a unique number like a sequence number with a per-key random secret salt. This improves security against pre-computation attacks and multi-key attacks [Bellare]. By increasing the nonce length from 96 bits to 224 bits, Rijndael-256-256-GCM-SST can offer significantly greater security against pre-computation and multi-key attacks compared to AES-256-GCM-SST.¶

The GCM-SST tag_length SHOULD NOT be smaller than 4 bytes and cannot be larger than 16 bytes. When tag_length < 128 - log2(n + m + 1) bits, the worst-case forgery probability is bounded by ≈ 2^-tag_length [Nyberg]. The tags in the AEAD algorithm listed in Section 4.3 therefore have an almost perfect security level. This is significantly better than GCM where the security level is only tag_length - log2(n + m + 1) bits [GCM]. Note that n and m in this context represent the maximum values allowed by the decryption function. For a graph of the forgery probability, refer to Fig. 3 in [Inoue]. As one can note, for 128-bit tags and long messages, the forgery probability is not close to ideal and similar to GCM [GCM]. If tag verification fails, the plaintext and expected_tag MUST NOT be given as output. In GCM-SST, the full_tag is independent of the specified tag length unless the application explicitly incorporates tag length into the keystream or the nonce.¶

When tag_length < 128 - log2(n + m + 1) bits, the expected number of forgeries is ≈ q ⋅ 2^-tag_length, where q is the number of decryption queries, which is ideal. This far outperforms GCM, where the expected number of forgeries is ≈ q² ⋅ (n + m + 1) ⋅ 2^{-tag_length + 1} [Multiple]. BSI states that an ideal MAC with a 96-bit tag length is considered acceptable for most applications [BSI], a requirement that GCM-SST with 96- and 112-bit tags satisfies. Achieving a comparable level of security with GCM, CCM, or Poly1305 is nearly impossible.¶

The confidentiality offered by AES-GCM-SST against passive attackers is equal to AES-GCM [GCM] and given by the birthday bound. Regardless of key length, an attacker can mount a distinguishing attack with a complexity of approximately 2¹²⁹ / k, where k is the number of invocations of the AES encryption function. In contrast, the confidentiality offered by Rijndael-256-256-GCM-SST against passive attackers is significantly higher. The complexity of distinguishing attacks for Rijndael-256-256-GCM-SST is approximately 2²⁵⁷ / k, where k is the number of invocations of the Rijndael-256-256 encryption function. While Rijndael-256-256 in counter mode can provide strong confidentiality for plaintexts much larger than 2³⁶ octets, GHASH and POLYVAL do not offer adequate integrity for long plaintexts. To ensure robust integrity for long plaintexts, an AEAD mode would need to replace POLYVAL with a MAC that has better security properties, such as a Carter-Wegman MAC in a larger field [Degabriele] or other alternatives such as [SMAC].¶

The confidentiality offered by AES-GCM-SST against active attackers is directly linked to the forgery probability. Depending on the protocol and application, forgeries MAY significantly compromise privacy, in addition to affecting integrity and authenticity. It MUST be assumed that attackers always receive feedback on the success or failure of their forgery attempts. Therefore, attacks on integrity, authenticity, and confidentiality MUST all be carefully evaluated when selecting an appropriate tag length.¶

As a practical example, in protocols like QUIC [RFC9001], where the size of plaintext and associated data is less than ≈ 2¹⁶ bytes, AEAD_AES_128_GCM_SST_14 offers superior confidentiality and integrity compared to AEAD_AES_128_GCM, while also reducing overhead by 2 bytes. Both algorithms provide similar security against passive attackers; however, AEAD_AES_128_GCM_SST_14 enhances security against active attackers by significantly reducing the expected number of successful forgeries.¶

In general, there is a very small possibility in GCM-SST that either or both of the subkeys H and Q are zero, so called weak keys. If H is zero, the authentication tag depends only on the length of P and A and not on their content. If Q is zero, the authentication tag does not depends on the field L encoding the length of P and A. There are no obvious ways to detect this condition for an attacker, and the specification admits this possibility in favor of complicating the flow with additional checks and regeneration of values. In AES-GCM-SST, H and Q are generated with a permutation on different input, so H and Q cannot both be zero.¶

The details of the replay protection mechanism is determined by the security protocol utilizing GCM-SST. If the nonce includes a sequence number, it can be used for replay protection. Alternatively, a separate sequence number can be used, provided there is a one-to-one mapping between sequence numbers and nonces. The choice of a replay protection mechanism depends on factors such as the expected degree of packet reordering, as well as protocol and implementation details. For examples of replay protection mechanisms, see [RFC4303] and [RFC6479].¶

6. IANA Considerations

IANA is requested to assign the entries in the first column of Table 1 to the "AEAD Algorithms" registry under the "Authenticated Encryption with Associated Data (AEAD) Parameters" heading with this document as reference.¶

7. References

Appendix A. AES-GCM-SST Test Vectors

       KEY = { 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f }
     NONCE = { 30 31 32 33 34 35 36 37 38 39 3a 3b }
         H = { 22 ce 92 da cb 50 77 4b ab 0d 18 29 3d 6e ae 7f }
         Q = { 03 13 63 96 74 be fa 86 4d fa fb 80 36 b7 a0 3c }
         M = { 9b 1d 49 ea 42 b0 0a ec b0 bc eb 8d d0 ef c2 b9 }

       AAD = { }
 PLAINTEXT = { }
encode-LEN = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  full-TAG = { 9b 1d 49 ea 42 b0 0a ec b0 bc eb 8d d0 ef c2 b9 }
       TAG = { 9b 1d 49 ea }
CIPHERTEXT = { }

       AAD = { 40 41 42 43 44 }
 PLAINTEXT = { }
encode-LEN = { 00 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 }
  full-TAG = { 7f f3 cb a4 d5 f3 08 a5 70 4e 2f d5 f2 3a e8 f9 }
       TAG = { 7f f3 cb a4 }
CIPHERTEXT = { }

       AAD = { }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b }
encode-LEN = { 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  full-TAG = { f8 de 17 85 fd 1a 90 d9 81 8f cb 7b 44 69 8a 8b }
       TAG = { f8 de 17 85 }
CIPHERTEXT = { 64 f0 5b ae 1e d2 40 3a 71 25 5e dd }

       AAD = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e }
encode-LEN = { f8 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 }
  full-TAG = { 93 43 56 14 0b 84 48 2c d0 14 c7 40 7e e9 cc b6 }
       TAG = { 93 43 56 14 }
CIPHERTEXT = { 64 f0 5b ae 1e d2 40 3a 71 25 5e dd 53 49 5c e1
               7d c0 cb c7 85 a7 a9 20 db 42 28 ff 63 32 10 }

       AAD = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 }
encode-LEN = { 88 00 00 00 00 00 00 00 78 00 00 00 00 00 00 00 }
  full-TAG = { f8 50 b7 97 11 43 ab e9 31 5a d7 eb 3b 0a 16 81 }
       TAG = { f8 50 b7 97 }
CIPHERTEXT = { 64 f0 5b ae 1e d2 40 3a 71 25 5e dd 53 49 5c e1
               7d }

       KEY = { 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9 eb }
     NONCE = { 9a 50 ee 40 78 36 fd 12 49 32 f6 9e }
       AAD = { 1f 03 5a 7d 09 38 25 1f 5d d4 cb fc 96 f5 45 3b
               13 0d }
 PLAINTEXT = { ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 32 3b a1 22
               f6 22 91 9d }
         H = { 2d 6d 7f 1c 52 a7 a0 6b f2 bc bd 23 75 47 03 88 }
         Q = { 3b fd 00 96 25 84 2a 86 65 71 a4 66 e5 62 05 92 }
         M = { 9e 6c 98 3e e0 6c 1a ab c8 99 b7 8d 57 32 0a f5 }
encode-LEN = { a0 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 }
  full-TAG = { 45 03 bf b0 96 82 39 b3 67 e9 70 c3 83 c5 10 6f }
       TAG = { 45 03 bf b0 96 82 39 b3 }
CIPHERTEXT = { b8 65 d5 16 07 83 11 73 21 f5 6c b0 75 45 16 b3
               da 9d b8 09 }

       KEY = { 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
               10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f }
     NONCE = { 30 31 32 33 34 35 36 37 38 39 3a 3b }
         H = { 3b d9 9f 8d 38 f0 2e a1 80 96 a4 b0 b1 d9 3b 1b }
         Q = { af 7f 54 00 16 aa b8 bc 91 56 d9 d1 83 59 cc e5 }
         M = { b3 35 31 c0 e9 6f 4a 03 2a 33 8e ec 12 99 3e 68 }

       AAD = { }
 PLAINTEXT = { }
encode-LEN = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  full-TAG = { b3 35 31 c0 e9 6f 4a 03 2a 33 8e ec 12 99 3e 68 }
       TAG = { b3 35 31 c0 e9 6f 4a 03 }
CIPHERTEXT = { }

       AAD = { 40 41 42 43 44 }
 PLAINTEXT = { }
encode-LEN = { 00 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 }
  full-TAG = { 63 ac ca 4d 20 9f b3 90 28 ff c3 17 04 01 67 61 }
       TAG = { 63 ac ca 4d 20 9f b3 90 }
CIPHERTEXT = { }

       AAD = { }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b }
encode-LEN = { 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
  full-TAG = { e1 de bf fd 5f 3a 85 e3 48 bd 6f cc 6e 62 10 90 }
       TAG = { e1 de bf fd 5f 3a 85 e3 }
CIPHERTEXT = { fc 46 2d 34 a7 5b 22 62 4f d7 3b 27 }

       AAD = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e }
encode-LEN = { f8 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 }
  full-TAG = { c3 5e d7 83 9f 21 f7 bb a5 a8 a2 8e 1f 49 ed 04 }
       TAG = { c3 5e d7 83 9f 21 f7 bb }
CIPHERTEXT = { fc 46 2d 34 a7 5b 22 62 4f d7 3b 27 84 de 10 51
               33 11 7e 17 58 b5 ed d0 d6 5d 68 32 06 bb ad }

       AAD = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e }
 PLAINTEXT = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 }
encode-LEN = { 88 00 00 00 00 00 00 00 78 00 00 00 00 00 00 00 }
  full-TAG = { 49 7c 14 77 67 a5 3d 57 64 ce fd 03 26 fe e7 b5 }
       TAG = { 49 7c 14 77 67 a5 3d 57 }
CIPHERTEXT = { fc 46 2d 34 a7 5b 22 62 4f d7 3b 27 84 de 10 51
               33 }

       KEY = { 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9 eb
               b3 a6 db 3c 87 0c 3e 99 24 5e 0d 1c 06 b7 b3 12 }
     NONCE = { 9a 50 ee 40 78 36 fd 12 49 32 f6 9e }
       AAD = { 1f 03 5a 7d 09 38 25 1f 5d d4 cb fc 96 f5 45 3b
               13 0d }
 PLAINTEXT = { ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 32 3b a1 22
               f6 22 91 9d }
         H = { 13 53 4b f7 8a 91 38 fd f5 41 65 7f c2 39 55 23 }
         Q = { 32 69 75 a3 3a ff ae ac af a8 fb d1 bd 62 66 95 }
         M = { 59 48 44 80 b6 cd 59 06 69 27 5e 7d 81 4a d1 74 }
encode-LEN = { a0 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 }
  full-TAG = { c4 a1 ca 9a 38 c6 73 af bf 9c 73 49 bf 3c d5 4d }
       TAG = { c4 a1 ca 9a 38 c6 73 af bf 9c }
CIPHERTEXT = { b5 c2 a4 07 f3 3e 99 88 de c1 2f 10 64 7b 3d 4f
               eb 8f f7 cc }

Change Log

This section is to be removed before publishing as an RFC.¶

Changes from -07 to -08:¶

• Replaced masking with non-zero injective padding as suggested by Inoue et al. This saves one AES invocation for 94% of plaintext lengths.¶

• Added a note explainting that "GCM allows universal forgery with lower complexity than GCM-SST, even when nonces are not reused", to avoid any misconceptions that Lindell's attack makes GCM-SST weaker than GCM in any way.¶

• Consideration on replay protection mechanisms¶

• Added a comparision between AEAD_AES_128_GCM_SST_14 and AEAD_AES_128_GCM in protocols like QUIC¶

Changes from -06 to -07:¶

• Replaced 80-bit tags with 96- and 112-bit tags.¶

• Changed P_MAX and A_MAX and made them tag_length dependent to enable 96- and 112-bit tags with near-ideal security.¶

• Clarified that GCM-SST tags have near-ideal forgery probabilities, even against multiple forgery attacks, which is not the case at all for GCM.¶

• Added formulas for expeted number of forgeries for GCM-SST (q ⋅ 2^-tag_length) and GCM (q² ⋅ (n + m + 1) ⋅ 2^{-tag_length + 1}) and stated that GCM-SST fulfils BSI recommendation of using 96-bit ideal MACs.¶

Changes from -04 to -06:¶

• Reference to Inoue et al. for security proof, forgery probability graph, and improved attack when GCM-SST is used without replay protection.¶

• Editorial changes.¶

Changes from -03 to -04:¶

• Added that GCM-SST is designed for unicast protocol with replay protection¶

• Update info on use cases for short tags¶

• Updated info on ETSI and 3GPP standardization of GCM-SST¶

• Added Rijndael-256-256¶

• Added that replay is required and that random nonces, multicast, and broadcast are forbidden based on attack from Yehuda Lindell¶

• Security considerations for active attacks on privacy as suggested by Thomas Bellebaum¶

• Improved text on H and Q being zero.¶

• Editorial changes.¶

Changes from -02 to -03:¶

• Added performance information and considerations.¶

• Editorial changes.¶

Changes from -01 to -02:¶

• The length encoding chunk is now called L¶

• Use of the notation POLYVAL(H, X_1, X_2, ...) from RFC 8452¶

• Removed duplicated text in security considerations.¶

Changes from -00 to -01:¶

• Link to NIST decision to remove support for GCM with tags shorter than 96-bits based on Mattsson et al.¶

• Mention that 3GPP 5G Advance will use GCM-SST with AES-256 and SNOW 5G.¶

• Corrected reference to step numbers during decryption¶

• Changed T to full_tag to align with tag and expected_tag¶

• Link to images from the NIST encryption workshop illustrating the GCM-SST encryption and decryption functions.¶

• Updated definitions¶

• Editorial changes.¶

Acknowledgments

The authors thank Richard Barnes, Thomas Bellebaum, Scott Fluhrer, Eric Lagergren, Yehuda Lindell, and Erik Thormarker for their valuable comments and feedback. Some of the formatting and text were inspired by and borrowed from [I-D.irtf-cfrg-aegis-aead].¶

Authors' Addresses