]> Amazon Web Services

Canada campagna@amazon.com

Ericsson

Sweden alexander.maximov@ericsson.com

Ericsson

Sweden john.mattsson@ericsson.com

IRTF Crypto Forum next generation unicorn sparkling distributed ledger quantum magic This document defines Galois Counter Mode with Strong Secure Tags (GCM-SST), an Authenticated Encryption with Associated Data (AEAD) algorithm that addresses several weaknesses of GCM. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. Main differences from GCM are the introduction of a second authentication subkey H₂, per-nonce derivation of both H and H₂, and stricter usage limits. Together, these changes yield authentication tags with near-ideal forgery probabilities, including reforgeability resistance. All registered instances have an expected number of forgeries E(F) ≈ v / 2^t, a property that GCM is far from providing. GCM-SST is designed for security protocols with replay protection such as TLS, QUIC, SRTP, and PDCP, and provides hardware and software performance comparable to GCM. This document registers nine AEAD algorithm instances using AES and Rijndael-256 in counter mode, with tag lengths of 48, 96, and 112 bits. GCM-SST has been standardized by 3GPP for use with SNOW 5G, AES-256, and ZUC-256. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Background and Motivation AES in Galois Counter Mode (AES-GCM) is a widely deployed Authenticated Encryption with Associated Data (AEAD) algorithm , valued for its performance in hardware and software, and its provable security. During NIST standardization, Ferguson identified two weaknesses in GCM's authentication function . The first significantly increases the forgery probability. The second allows recovery of the authentication subkey H upon a successful forgery, enabling arbitrary subsequent forgeries, a property known as reforgeability failure. Both weaknesses affect all tag lengths, but are especially damaging with short tags. Nyberg et al. showed that small, theoretically grounded changes would mitigate these weaknesses, but NIST instead imposed ad hoc restrictions for short tags. Mattsson et al. later showed that attackers can nearly always observe whether a forgery succeeded, contradicting NIST's assumptions. NIST is now planning to remove support for tags shorter than 96 bits , but has not addressed the underlying authentication weaknesses. A third weakness is that GCM does not impose sufficiently strict limits on the number of invocations and the lengths of plaintext and associated data. Even with 96-bit tags, AES-GCM offers only a forgery probability of 2^-39, and with 128-bit tags in QUIC , the expected number of forgeries, E(F), is worse than that of an ideal 65-bit MAC. Reforgeability resistance is a core design criterion in modern AEAD schemes . Short tags are widely used: 32-bit tags are standard in most radio link layers including 5G , 64-bit tags are very common in IoT transport and application layers, and 32-, 64-, and 80-bit tags appear frequently in media encryption. Audio packets are small, numerous, and ephemeral, making them highly sensitive to cryptographic overhead; since each packet typically encodes only 20 ms of audio, forgery of individual packets is and barely noticeable. Due to its weaknesses, GCM is typically not used with short tags, forcing a choice between the overhead of unnecessarily long tags and much slower constructions such as AES-CTR with HMAC . Short tags are also useful in packets whose payloads are secured at higher layers, in protocols where security is given by the sum of tag lengths, and in constrained radio networks where low bandwidth limits forgery attempts. For all these applications, it is essential that the MAC behaves ideally: the forgery probability should be ≈ 1 / 2^t, where t is the tag length in bits, even after many encryptions, many forgery attempts, and a successful forgery. CCM achieves near-ideal probabilities with short tags but at a performance penalty relative to GCM.

Galois Counter Mode with Strong Secure Tags (GCM-SST) This document defines GCM with Strong Secure Tags (GCM-SST), an AEAD algorithm that addresses these weaknesses. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. The differences from GCM are: the introduction of a second authentication subkey H₂, per-nonce derivation of H and H₂, stricter usage limits, fixed-length deterministic nonces, and the replacement of GHASH with POLYVAL . Together, these changes yield truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, and provide nonce-misuse resilience. GCM-SST is designed for use in security protocols with replay protection such as TLS , QUIC , SRTP , and PDCP . In unicast settings with replay protection, GCM-SST's authentication tag behaves as an ideal MAC with full reforgeability resistance. Compared to Poly1305 and GCM , GCM-SST achieves stronger integrity with less overhead. Its hardware and software performance is comparable to GCM; in software, the two additional AES invocations are offset by POLYVAL's advantage over GHASH on little-endian architectures. GCM-SST preserves GCM's additive encryption structure, enabling efficient implementations on modern processors . This document also registers GCM-SST instances using AES and Rijndael with 256-bit keys and blocks (Rijndael-256) in counter mode, with tag lengths of 48, 96, and 112 bits. These instances address the strong industry demand for fast authenticated encryption with minimal overhead and strong security. All registered instances achieve an expected number of forgeries E(F) ≈ v / 2^t, where v is the number of forgery attempts, matching the behavior of an ideal MAC. This is a property expected of a modern AEAD but one that GCM does not provide. Rijndael-256 is already standardized by 3GPP for authentication and key generation and is planned for NIST standardization . On modern x86 platforms with AES-NI and VAES instructions, Rijndael-256 performs efficiently . Compared to AEGIS , AES-GCM-SST offers substantially higher throughput in dedicated hardware while retaining the advantage of being a mode of operation for AES. GCM-SST was originally developed by ETSI SAGE and subsequently standardized by 3GPP for use with SNOW 5G , AES-256 , and ZUC-256 in 3GPP TS 35.240–35.248. Security proofs for GCM-SST in single- and multi-key settings are provided by Inoue et al. and Naito et al. . specifies GCM-SST, registers AEAD algorithms using AES and Rijndael-256, and discusses security considerations.

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 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
• N is the nonce, as defined in
• A is the associated data, as defined in
• P is the plaintext, as defined in
• Z is the keystream
• ct is the ciphertext
• tag is the authentication tag
• t is the authentication tag length, in bits
• b is the block size, in bits
• v is the number of forgery attempts
• = is the assignment operator
• ≠ is the inequality operator
• x || y is concatenation of the byte strings x and y
• ⊕ is the bitwise exclusive-OR (XOR) operator
• len(x) is the length of x in bits
• zeropad(x) right-pads the byte string x with zeros to a multiple of 128 bits
• truncate(x, y) retains the first y bits of x and discards the remainder
• n is the number of 128-bit chunks in zeropad(P)
• m is the number of 128-bit chunks in zeropad(A)
• POLYVAL is defined in
• 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[x] is the 128-bit chunk at index x in array V; the first chunk has index 0
• V[x:y] is the range of 128-bit chunks at indices x through y in array V

Galois Counter Mode with Strong Secure Tags (GCM-SST) This section defines the GCM-SST AEAD algorithm following the recommendations of Nyberg et al. . GCM-SST is defined with a general interface so that it can be used with any keystream generator, not only a 128-bit block cipher. GCM-SST adheres to the AEAD interface defined in . The encryption function takes four variable-length byte string parameters: a secret key K, a nonce N, 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. The first three chunks Z[0], Z[1], and Z[2] are used as authentication subkeys H and H₂, and masking subkey M, respectively. The subsequent chunks Z[3], Z[4], ..., Z[n + 2] are used to encrypt the plaintext. In place of GHASH , GCM-SST uses the POLYVAL function from AES-GCM-SIV , which yields more efficient software implementations on little-endian architectures. GHASH and POLYVAL can be defined in terms of one another, as shown in . The subkeys H and H₂ are field elements used as inputs to POLYVAL, while the subkey M is used for the final masking of the tag. Both the encryption and decryption functions are defined only on inputs comprising a whole number of bytes. Figures illustrating the GCM-SST encryption and decryption functions can be found in . For every computational procedure specified in this document, a conforming implementation MAY replace the given steps with any mathematically equivalent steps, provided the output is correct for every valid input.

Authenticated Encryption Function The encryption function Encrypt(K, N, A, P) encrypts a plaintext and returns the ciphertext together with an authentication tag that verifies the authenticity of both the plaintext and associated data, if provided. Prerequisites and security requirements:

• The key MUST be chosen uniformly at random.
• For a given key, each nonce MUST be unique; random nonces MUST NOT be used.
• Each key MUST be restricted to a single tag length t.
• Supported input and output lengths MUST be defined.

Inputs:

• Key K (variable-length byte string)
• Nonce N (variable-length byte string)
• Associated data A (variable-length byte string)
• Plaintext P (variable-length byte string)

Outputs:

• Ciphertext ct (variable-length byte string)
• tag (a byte string of length t / 8)

Steps:

1. If the lengths of K, N, A, P are not supported, return an error and abort
2. Instantiate the keystream generator with K and N
3. Let H = Z[0], H₂ = Z[1], M = Z[2]
4. Let ct = P ⊕ truncate(Z[3:n + 2], len(P))
5. Let S = zeropad(A) || zeropad(ct)
6. Let L = LE64(len(ct)) || LE64(len(A))
7. Let X = POLYVAL(H, S[0], S[1], ...)
8. Let full_tag = POLYVAL(H₂, X ⊕ L) ⊕ M
9. Let tag = truncate(full_tag, t)
10. Return (ct, tag)

The encoding of L aligns with existing implementations of GCM.

Authenticated Decryption Function The decryption function Decrypt(K, N, A, ct, tag) decrypts a ciphertext, verifies that the authentication tag is correct, and returns the plaintext on success or an error otherwise. Prerequisites and security requirements:

• The calculation of the plaintext P (step 10) MAY be done in parallel with tag verification (steps 3–9). If tag verification fails, the plaintext P MUST NOT be given as output.
• Each key MUST be restricted to a single tag length t.
• Supported input and output lengths MUST be defined.

Inputs:

• Key K (variable-length byte string)
• Nonce N (variable-length byte string)
• Associated data A (variable-length byte string)
• Ciphertext ct (variable-length byte string)
• tag (a byte string of length t / 8)

Outputs:

• Plaintext P (variable-length byte string), or an error indicating that the authentication tag is invalid for the given inputs.

Steps:

1. If the lengths of K, N, A, or ct are not supported, or if len(tag) ≠ t, return an error and abort
2. Instantiate the keystream generator with K and N
3. Let H = Z[0], H₂ = Z[1], M = Z[2]
4. Let S = zeropad(A) || zeropad(ct)
5. Let L = LE64(len(ct)) || LE64(len(A))
6. Let X = POLYVAL(H, S[0], S[1], ...)
7. Let full_tag = POLYVAL(H₂, X ⊕ L) ⊕ M
8. Let expected_tag = truncate(full_tag, t)
9. If tag ≠ expected_tag, return an error and abort
10. Let P = ct ⊕ truncate(Z[3:n + 2], len(ct))
11. If N fails replay protection, return an error and abort
12. Return P

The comparison of tag and expected_tag in step 9 MUST be performed in constant time to prevent information leakage about the position of the first mismatched byte. For a given key, a plaintext MUST NOT be returned unless it is certain that no plaintext has previously been returned for the same nonce. Replay protection MAY be performed either before step 1 or during step 11. Protocols with nonce-hiding mechanisms , such as QUIC , implement replay protection after decryption to mitigate timing side-channel attacks. If tag validation or replay protection fails, intermediate values such as H, H₂, M, Z, P, X, full_tag, and expected_tag MUST be destroyed (zeroized).

Encoding (ct, tag) Tuples Applications MAY store the ciphertext and the authentication tag in separate structures or encode both as a single byte string C. In the latter case, the tag MUST immediately follow the ciphertext ct:

• C = ct || tag .

AES and Rijndael-256 in GCM-SST This section defines instantiations of GCM-SST using AES and Rijndael-256.

AES-GCM-SST When GCM-SST is instantiated with AES (AES-GCM-SST), the keystream generator is AES in counter mode

• Z[i] = ENC(K, N || BE32(i)) ,

where ENC is the AES Cipher function . The use of big-endian counters aligns with existing AES counter mode implementations.

Rijndael-GCM-SST When GCM-SST is instantiated with Rijndael-256 (Rijndael-GCM-SST), the keystream generator is Rijndael-256 in counter mode

• Z[2i] = ENC(K, N || BE32(i))[0] ,
• Z[2i+1] = ENC(K, N || BE32(i))[1] ,

where ENC is the Rijndael-256 Cipher function .

AEAD Instances and Constraints Nine AEAD algorithm instances are defined below, following the format of . These instances use AES-GCM-SST or Rijndael-GCM-SST with tag lengths of 48, 96, or 112 bits. AEAD Algorithm Instances for AES-GCM-SST and Rijndael-GCM-SST

Name	K_LEN (bytes)	P_MAX = A_MAX (bytes)	Tag length t (bits)
AEAD_AES_128_GCM_SST_6	16	236 - 48	48
AEAD_AES_128_GCM_SST_12	16	232	96
AEAD_AES_128_GCM_SST_14	16	216	112
AEAD_AES_256_GCM_SST_6	32	236 - 48	48
AEAD_AES_256_GCM_SST_12	32	232	96
AEAD_AES_256_GCM_SST_14	32	216	112
AEAD_RIJNDAEL_GCM_SST_6	32	237 - 48	48
AEAD_RIJNDAEL_GCM_SST_12	32	232	96
AEAD_RIJNDAEL_GCM_SST_14	32	216	112

The following parameters apply to all the instances:

• N_MIN = N_MAX (minimum and maximum nonce length) is 12 bytes for AES-GCM-SST and 28 bytes for Rijndael-GCM-SST.
• C_MAX (maximum ciphertext length, including the tag) is P_MAX + t / 8 bytes.
• Q_MAX (maximum number of encryption function invocations) is 2³² for AES-GCM-SST and 2⁶⁴ for Rijndael-GCM-SST.
• V_MAX (maximum number of decryption function invocations) is 2⁵⁴ for AES-GCM-SST and 2¹¹⁸ for Rijndael-GCM-SST.

Assuming a sufficiently large key size such that brute-force key-recovery attacks can be neglected, a strong integrity mechanism should satisfy

• E(F) ≈ v / 2^t ,

for all permitted invocation counts, plaintext lengths, associated data lengths, and tag lengths. This is how users expect MAC algorithms to behave, i.e., the behavior of an ideal MAC. The limits specified for AES-GCM-SST and Rijndael-GCM-SST are chosen to achieve this property in unicast settings with replay protection and are therefore more restrictive than the corresponding limits for GCM in . To ensure that v / 2^t is the dominant term in the integrity advantage for all permitted plaintext and associated data lengths, this document sets:

• P_MAX = A_MAX = min(2^{128 - t}, 2³² ⋅ b / 8 - 48) ,

where b is the block size in bits. This ensures that the integrity advantage is ≈ δ ⋅ v / 2^t. To ensure that the Bernstein bound factor satisfies δ ≈ 1, protocols using AES-GCM-SST MUST enforce stricter limits on Q_MAX and/or P_MAX such that:

• Q_MAX ⋅ P_MAX / 16 + V_MAX ⪅ 2⁵⁹ .

The Bernstein bound factor satisfies δ(a) ≈ 1 + a² / 2^b+1 . Following the analysis in , this document conservatively upper-bounds a by Q_MAX ⋅ P_MAX / 16 + V_MAX. For AES, the 128-bit block size implies that achieving δ ≈ 1 requires balancing the constraints on Q_MAX and P_MAX. For Rijndael-256, the 256-bit block size already guarantees δ ≈ 1. Protocols employing Rijndael-GCM-SST MAY impose stricter limits on P_MAX, A_MAX, Q_MAX, and V_MAX. In addition to bounding δ, the Q_MAX and P_MAX constraints establish a minimum complexity for distinguishing attacks and an upper bound on the fraction of plaintext bits recoverable by an attacker. This aligns with the European recommendation of limiting the number of block-cipher invocations to 2^b/2-5. This ensures that an attacker cannot recover more than ≈ 0.0007 bits across all plaintexts and that δ ⪅ 1.0005. To align with zero-trust principles and minimize the impact of key compromise, protocols using GCM-SST SHOULD enforce rekeying well before reaching the cryptographic limits. Modern guidance recommends rekeying via ephemeral key exchange providing Forward Secrecy (FS) and Post-Compromise Security (PCS) after 1 hour or 2³⁰–2³⁷ bytes .

Security Considerations GCM-SST introduces a second authentication subkey H₂, alongside the subkey H. The inclusion of H₂ enables truncated tags with forgery probabilities close to ideal. Both H 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 follow the recommendations in . Inoue et al. prove that GCM-SST achieves its v / 2^t design goal in the single-key setting, and that it provides nonce-misuse resilience . Because the subkeys in GCM-SST are derived independently per nonce, any confidentiality or integrity advantage an adversary gains against one nonce, whether through nonce misuse or a successful forgery attempt, does not carry over to a different, fresh nonce: GCM-SST recovers its full security as soon as such a nonce is no longer in use. Naito et al. derive a tighter single-key bound and further prove that GCM-SST achieves its v / 2^t design goal in the multi-key setting, including when combined with nonce randomization and nonce-based key derivation. GCM-SST is designed for use in security protocols with replay protection. Each key MUST be chosen uniformly at random. GCM-SST MUST be used in a nonce-respecting setting: for a given key, a nonce MUST be used at most once in the encryption function and at most 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. The reuse of nonces in successful encryption and decryption function calls enables universal forgery, as demonstrated by , , and , and so GCM-SST MUST be used with replay protection. Additionally, GCM-SST MUST NOT be used with random nonces: besides reducing the efficiency of replay protection, they introduce a nonce-collision probability that degrades security bounds. Implementations SHOULD add randomness to the nonce by XORing a unique number such as a sequence number with a per-key random secret salt of the same length as the nonce. This significantly improves security against precomputation and multi-key attacks and is implemented, for example, in TLS 1.3 , OSCORE , and . By increasing the nonce length from 96 bits to 224 bits, Rijndael-GCM-SST can offer significantly greater security against precomputation and multi-key attacks compared to AES-GCM-SST. GCM-SST does not aim for full nonce-misuse resistance . Like GCM, it derives its keystream in a single pass, avoiding the two-pass, non-online structure that nonce-misuse-resistant algorithms require. NIST is addressing nonce-misuse resistance through the planned Accordions . Unless otherwise specified, formulas for the expected number of forgeries apply to unicast scenarios.

Integrity The GCM-SST tag length t SHOULD NOT be smaller than 32 bits and cannot be larger than 128 bits. Let ℓ = (P_MAX + A_MAX) / 16 + 1. When ℓ ≪ 2^{128 - t}, the forgery probability is ≈ 1 / 2^t . The tags in the AEAD algorithms listed in therefore achieve near-ideal forgery probabilities. This is a significant improvement over GCM , where the forgery probability is bounded by ⪅ δ ⋅ ℓ / 2^t . For a graph of the forgery probability assuming δ ≈ 1, see Fig. 3 in . For 128-bit tags and long messages, the forgery probability of GCM-SST is no longer ideal and becomes comparable to that of GCM. In GCM-SST, the full_tag is independent of t unless the application explicitly incorporates t into the keystream or the nonce. The expected number of forgeries depends on the keystream generator. For block ciphers in counter mode, it is governed by the birthday bound, with AES-based ciphers particularly constrained by their narrow 128-bit block size. Assuming a sufficiently large key size such that brute-force key-recovery attacks can be neglected, a strong integrity mechanism should satisfy

• E(F) ≈ v / 2^t ,

where v is the number of forgery attempts. Following the constraints in , AES-GCM-SST and Rijndael-GCM-SST achieve this ideal. AES-GCM-SST significantly outperforms AES-GCM , for which the expected number of forgeries (assuming deterministic 96-bit nonces) is bounded by:

• E(F) ⪅ δ ⋅ v² ⋅ ℓ / 2^t+1 .

For further details on the integrity advantages and expected number of forgeries for GCM and GCM-SST, see , , , , and . BSI states that an ideal MAC with a 96-bit tag length is considered acceptable for most applications , a requirement that GCM-SST with 96-bit tags satisfies when ℓ ⪅ 2³² and δ ≈ 1. Achieving a comparable level of security with GCM, CCM, or Poly1305 is nearly impossible.

Confidentiality The confidentiality offered by GCM-SST against passive attackers depends on the keystream generator. For block ciphers in counter mode, it is governed by the birthday bound, with AES-based ciphers particularly constrained by their narrow 128-bit block size. For AES-GCM-SST, the confidentiality is equal to AES-GCM . Regardless of key length, an attacker can mount a distinguishing attack with a complexity of approximately 2¹²⁹ / σ, where σ ⪅ P_MAX ⋅ Q_MAX / 16 is the total plaintext length measured in 128-bit chunks. In contrast, the confidentiality offered by Rijndael-GCM-SST against passive attackers is significantly higher. The complexity of distinguishing attacks for Rijndael-GCM-SST is approximately 2²⁵⁸ / σ. McGrew and Leurent and Sibleyras demonstrate that for block ciphers in counter mode, an attacker with partial knowledge of the plaintext can execute plaintext-recovery attacks against counter mode with roughly the same complexity (up to logarithmic factors) as distinguishing attacks. However, Preuß Mattsson demonstrated that an attacker cannot recover more than ≈ σ² / 2^b bits of the plaintext. Given the constraints outlined in , an attacker cannot recover more than 0.0007 bits of AES-GCM-SST plaintexts. While Rijndael-256 in counter mode can provide high confidentiality for plaintexts much larger than 2³⁷ bytes, 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 or other alternatives such as . The confidentiality offered by GCM-SST against active attackers is directly linked to the forgery probability. Depending on the protocol and application, forgeries can 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.

Weak Keys In general, there is a very small possibility in GCM-SST that either or both of the subkeys H and H₂ 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 H₂ is zero, the authentication tag does not depend on P and A. Due to the masking with M, there are no obvious ways to detect this condition for an attacker, and the specification admits this possibility rather than complicating implementations with additional checks and regeneration of values. In AES-GCM-SST, H and H₂ are generated with a permutation on different inputs, so H and H₂ cannot both be zero.

Replay Protection The details of the replay protection mechanism are 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 and . Implementing replay protection by requiring ciphertexts to arrive in order and terminating the connection if a single decryption fails is NOT RECOMMENDED, as this approach reduces robustness and availability and exposes the system to denial-of-service attacks .

Comparison with ChaCha20-Poly1305 and AES-GCM compares the integrity of GCM-SST, ChaCha20-Poly1305 , and AES-GCM in unicast security protocols with replay protection. In both Poly1305 and GCM, the forgery probability depends on ℓ; in GCM, it additionally involves the Bernstein bound factor δ. GCM-SST requires δ ≈ 1, a property that GCM does not mandate. Furthermore, GCM provides no reforgeability resistance, which substantially increases the expected number of forgeries. See , , and for further details. Comparison of integrity among GCM-SST, ChaCha20-Poly1305, and AES-GCM in unicast security protocols with replay protection. v is the number of forgery attempts, ℓ is the maximum length of plaintext and associated data, measured in 128-bit chunks. The GCM values assume δ ≈ 1; when this condition does not hold, the GCM values are worse than those shown.

Name	Tag length (bytes)	Forgery probability before first forgery	Forgery probability after first forgery	Expected number of forgeries
GCM_SST_14	14	1 / 2112	1 / 2112	v / 2112
GCM_SST_12	12	1 / 296	1 / 296	v / 296
POLY1305	16	ℓ / 2103	ℓ / 2103	v ⋅ ℓ / 2103
GCM	16	ℓ / 2128	1	v2 ⋅ ℓ / 2129

compares the integrity of GCM-SST, ChaCha20-Poly1305 , and AES-GCM in unicast QUIC , a security protocol with mandatory replay protection, and where the combined size of plaintext and associated data is less than ≈ 2¹⁶ bytes (ℓ ≈ 2¹²). GCM_SST_14 and GCM_SST_12 provide better integrity than ChaCha20-Poly1305 and AES-GCM , while also reducing overhead by 2–4 bytes. For GCM-SST and ChaCha20-Poly1305, the expected number of forgeries is linear in v when replay protection is employed. ChaCha20-Poly1305 achieves a security level equivalent to that of an ideal MAC with a length of 91 bits. For AES-GCM, replay protection does not mitigate reforgeries, the expected number of forgeries grows quadratically with v, and GCM provides significantly worse integrity than GCM-SST and ChaCha20-Poly1305 unless v is kept very small. With v = 2⁵² as allowed for AES-GCM in QUIC , the expected number of forgeries for AES-GCM exceeds that of an ideal 65-bit MAC. Comparison of integrity among GCM-SST, ChaCha20-Poly1305, and AES-GCM in unicast QUIC, where the maximum packet size is 65536 bytes. The GCM values assume δ ≈ 1; when this condition does not hold, the GCM values are worse than those shown.

Name	Tag length (bytes)	Forgery probability before first forgery	Forgery probability after first forgery	Expected number of forgeries
GCM_SST_14	14	1 / 2112	1 / 2112	v / 2112
GCM_SST_12	12	1 / 296	1 / 296	v / 296
POLY1305	16	1 / 291	1 / 291	v / 291
GCM	16	1 / 2116	1	v2 / 2117

compares the confidentiality of Rijndael-GCM-SST, AES-256-GCM-SST, SNOW 5G-GCM-SST, and ChaCha20-Poly1305 , all of which use 256-bit keys, against passive attackers. The confidentiality of block ciphers in counter mode is governed by the birthday bound, with AES-based ciphers particularly constrained by their narrow 128-bit block size. While plaintext-recovery attacks on block ciphers in counter mode have a complexity similar to distinguishing attacks, the attacker cannot recover more than ≈ σ² / 2^b bits of the plaintexts . Comparison of confidentiality against passive attackers among Rijndael-GCM-SST, SNOW 5G-GCM-SST, ChaCha20-Poly1305, and AES-256-GCM-SST. σ is the total plaintext length measured in 128-bit chunks.

Name	Key size (bits)	Complexity of distinguishing attacks
CHACHA20_POLY1305	256	2256
SNOW_5G_GCM_SST	256	2256
RIJNDAEL_GCM_SST	256	≈ 2258 / σ
AES_256_GCM_SST	256	≈ 2129 / σ

Multicast and Broadcast While GCM-SST offers stronger security properties than GCM for a given tag length in multicast or broadcast contexts, it does not behave exactly like an ideal MAC. With an ideal MAC, a successful forgery against one recipient allows the attacker to reuse the same forgery against all other recipients. In contrast, with GCM, a successful forgery against one recipient enables the attacker to generate an unlimited number of new forgeries for all recipients. With GCM-SST, a few successful forgeries against a few recipients allow the attacker to create one new forgery for all other recipients. While the total number of forgeries in GCM-SST matches that of an ideal MAC, the diversity of these forgeries is higher. To achieve one distinct forgery per recipient with an ideal MAC, the attacker would need to send on average 2^t forgery attempts to each recipient. In one-to-many scenarios with replay protection and r recipients, the expected number of distinct forgeries is ≈ v ⋅ r / 2^t.

IANA Considerations IANA is requested to assign the algorithm names listed in the first column of to the "AEAD Algorithms" registry under the registry group "Authenticated Encryption with Associated Data (AEAD) Parameters", with this document as the reference.

References Normative References This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead.

AES-GCM-SST Test Vectors

AES-GCM-SST Test #1 (128-bit key)

Case #1a

Case #1b

Case #1c

Case #1d

Case #1e

AES-GCM-SST Test #2 (128-bit key)

AES-GCM-SST Test #3 (256-bit key)

Case #3a

Case #3b

Case #3c

Case #3d

Case #3e

AES-GCM-SST Test #4 (256-bit key)

Compatibility with 3GPP Algorithms The integrity part of GCM-SST was originally developed by ETSI SAGE, under the name Mac5G, following a request from 3GPP. Mac5G follows the same structural approach as the integrity algorithms used for SNOW 3G and ZUC . 3GPP has standardized GCM-SST for use with SNOW 5G , AES-256 , and ZUC-256 in 3GPP TS 35.240–35.248. These AEAD algorithms are designated as NCA4, NCA5, and NCA6, respectively. GCM-SST, as specified in this document, is fully compatible with the SNOW 5G-based NCA4 and the ZUC-256-based NCA6. The AES-based NCA5 differs only in its subkey generation but is otherwise identical. The NCA algorithms support bit-aligned associated data and plaintext inputs, whereas this specification is restricted to byte-aligned inputs. They also provide more detailed specifications for nonce construction based on 3GPP protocol requirements. SNOW 5G is functionally equivalent to SNOW-Vi , except that the finite-state machine (FSM) adders have been changed from 32-bit to 16-bit operations to increase the complexity of correlation attacks while also improving implementation efficiency . The version of GCM-SST specified in this document imposes stricter security considerations and constraints than the ETSI SAGE specifications for the NCA algorithms. This document recommends that 3GPP adopt the additional security measures described herein.

Change Log Changes from -18 to -19:

• 3GPP standardization status updated from prospective to completed, now citing final TS 35.240–35.248 specifications instead of WIDs and Liaison Statements.
• Added a more complete description of 3GPP NCA4, NCA5, NCA6.
• New citation to Naito et al. for a tighter single-key bound and a proof of the multi-key bound, and a more complete description of Inoue et al.'s single-key security results.
• Significantly revised usage limits (P_MAX, A_MAX, Q_MAX, V_MAX) with clearer motivation for P_MAX and the δ ≈ 1 condition.
• Restructured decryption steps so that replay-protection failure is an explicit abort step, and added a requirement to zeroize intermediate values on tag or replay failure.
• Added zero-trust key compromise rekeying considerations.
• Added nonce-misuse resilience discussion.
• Added a more complete description of technical changes compared to NIST SP 800-38D (stricter usage limits, fixed-length deterministic nonces).
• Corrected the GCM formulas: E(F) ⪅ δ ⋅ v² ⋅ l / 2^t+1 is a bound; other formulas assume δ ≈ 1 as well as deterministic 96-bit nonces.
• Substantial editorial changes including terminology cleanup (tag_length -> t, octet string -> byte string).

Acknowledgments The authors thank , , , , , , , , , , , and for their valuable comments and feedback. Some of the formatting and text follow the conventions of .