]> 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 This document defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm. GCM-SST can be used with any keystream generator, not just 128-bit block ciphers. The main differences from GCM are the use 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. This enables truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, which are significant security improvements over GCM. GCM-SST is designed for unicast security protocols with replay protection and addresses the strong industry demand for fast encryption with minimal overhead and high security. This document registers several instances of GCM-SST using Advanced Encryption Standard (AES) and Rijndael-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 Advanced Encryption Standard (AES) in Galois Counter Mode (AES-GCM) is a widely used AEAD algorithm 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 . The first weakness significantly increases the probability of successful forgery for long messages. 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. The two weaknesses are problematic for all tag lengths but are especially critical when short tags are used. In a comment to NIST, Nyberg et al. 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 . NIST did not give any motivations for the parameter choices or the assumed security levels. Mattsson et al. 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 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 . NIST has not addressed the weaknesses for longer tags, such as the absence of reforgeability resistance . When AES-GCM is used in QUIC , the expected number of forgeries can be equivalent to that of an ideal MAC with a length of 64.4 bits. Reforgeability resistance is a key design criterion in modern AEAD algorithms . Short tags are widely used, 32-bit tags are standard in most radio link layers including 5G , 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 as each packet typically encodes only 20 ms of audio, forgery of individual packets is not a big concern and barely noticeable. Due to its weaknesses, GCM is typically not used with short tags. The result is either decreased performance from larger than needed tags , or decreased performance from using much slower constructions such as AES-CTR combined with HMAC . 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. While Counter with CBC-MAC (CCM) with short tags has forgery probabilities close to ideal, its performance is lower than that of GCM. For a comprehensive discussion on the use cases and requirements of short tags, see . This document defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD) algorithm following the recommendations from Nyberg et al. . 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 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 , see . These changes enable truncated tags with near-ideal forgery probabilities, even against multiple forgery attacks, see . GCM-SST is designed for use in unicast security protocols with replay protection such as TLS , QUIC , SRTP , and PDCP , where its authentication tag behaves like an ideal MAC, including reforgeability resistance. Users and implementors of cryptography expect algorithms to behave like ideal MACs. Compared to Poly1305 and GCM , GCM-SST can provide better integrity with less overhead. Its performance in hardware and software is similar to GCM . In software, the two additional AES invocations are 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 and Section 2.4 of . This document also registers several GCM-SST instances using Advanced Encryption Standard (AES) and Rijndael with 256-bit keys and blocks (Rijndael-256) in counter mode as keystream generators and with tag lengths of 48, 96, and 112 bits, see . The authentication tags in all registered GCM-SST instances behave like ideal MACs, which is not the case at all for GCM . 3GPP has standardized the use of Rijndael-256 for authentication and key generation in 3GPP TS 35.234–35.237 . NIST plans to standardize Rijndael-256 , although there might be revisions to the key schedule. Rijndael-256 has very good performance on modern x86-64 platforms equipped with AES-NI and VAES instructions . Compared to AEGIS , AES-GCM-SST offers significantly higher performance in pure hardware implementations while retaining the advantage of being a mode of operation for AES. 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 . Mac5G is constructed similarly to the integrity algorithms used for SNOW 3G and ZUC . 3GPP has decided to standardize GCM-SST for use with AES-256 , SNOW 5G , and ZUC-256 in 3GPP TS 35.240–35.248 .

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
• = is the assignment operator
• != is the inequality operator
• x || y is concatenation of the octet strings x and y
• ⊕ is the bitwise exclusive or operator XOR
• 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(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[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

Galois Counter Mode with Strong Secure Tags (GCM-SST) This section defines the Galois Counter Mode with Strong Secure Tags (GCM-SST) AEAD algorithm following the recommendations from Nyberg et al. . 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 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 three chunks Z[0], Z[1], and Z[2] are used as the three subkeys H, Q, and M. The following keystream chunks Z[3], Z[4], ..., Z[n + 2] are used to encrypt the plaintext. Instead of GHASH , GCM-SST makes use of the POLYVAL function from AES-GCM-SIV , which results in more efficient software implementations on little-endian architectures. GHASH and POLYVAL can be defined in terms of one another . The subkeys H and Q are field elements used in POLYVAL while the subkey M is used for the final masking of the tag. Both encryption and decryption are only defined on inputs that are a whole number of octets. Figures illustrating the GCM-SST encryption and decryption functions can be found in , , and . For every computational procedure that is specified in this document, a conforming implementation MAY replace the given set of steps with any mathematically equivalent set of steps. In other words, different procedures that produce the correct output for every input are permitted.

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

• The key MUST be randomly chosen from a uniform distribution.
• For a given key, a nonce MUST NOT be reused under any circumstances.
• Each key MUST be restricted to a single tag_length.
• Definitions of supported input-output lengths.

Inputs:

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

Outputs:

• Ciphertext ct (variable-length octet string)
• Tag tag (octet string with length tag_length)

Steps:

1. If the lengths of K, N, A, P are not supported return error and abort
2. Initiate keystream generator with K and N
3. Let H = Z[0], Q = 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(Q, X ⊕ L) ⊕ M
9. Let tag = truncate(full_tag, tag_length)
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 if the tag verification failed. Prerequisites and security:

• The calculation of the plaintext P (step 10) MAY be done in parallel with the tag verification (step 3-9). If the tag verification fails, the plaintext P and the expected_tag MUST NOT be given as output.
• Each key MUST be restricted to a single tag_length.
• Definitions of supported input-output lengths.

Inputs:

• Key K (variable-length octet string)
• Nonce N (variable-length octet string)
• Associated data A (variable-length octet string)
• Ciphertext ct (variable-length octet string)
• Tag tag (octet string with length tag_length)

Outputs:

• Plaintext P (variable-length octet 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) != tag_length return error and abort
2. Initiate keystream generator with K and N
3. Let H = Z[0], Q = 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(Q, X ⊕ L) ⊕ M
8. Let expected_tag = truncate(full_tag, tag_length)
9. If tag != expected_tag, return error and abort
10. Let P = ct ⊕ truncate(Z[3:n + 2], len(ct))
11. If N passes replay protection, return P

The comparison of tag and expected_tag in step 9 MUST be performed in constant time to prevent any 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 a plaintext has not been returned for the same nonce. Replay protection can 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.

Encoding (ct, tag) Tuples Applications MAY keep the ciphertext and the authentication tag in distinct structures or encode both as a single octet 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 Advanced Encryption Standard (AES) and Rijndael with 256-bit keys and blocks (Rijndael-256) in Galois Counter Mode with Strong Secure Tags.

AES-GCM-SST When GCM-SSM 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 . Big-endian counters align with existing implementations of AES in counter mode.

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 We define nine AEAD instances, in the format of , that use AES-GCM-SST and Rijndael-GCM-SST with tag lengths of 48, 96, and 112 bits. The key length and tag length are related to different security properties, and an application encrypting audio packets with short tags might require high confidentiality. AEAD Algorithms

Name	K_LEN (bytes)	P_MAX = A_MAX (bytes)	tag_length (bits)
AEAD_AES_128_GCM_SST_6	16	236 - 48	48
AEAD_AES_128_GCM_SST_12	16	235	96
AEAD_AES_128_GCM_SST_14	16	219	112
AEAD_AES_256_GCM_SST_6	32	236 - 48	48
AEAD_AES_256_GCM_SST_12	32	235	96
AEAD_AES_256_GCM_SST_14	32	219	112
AEAD_RIJNDAEL_GCM_SST_6	32	236 - 48	48
AEAD_RIJNDAEL_GCM_SST_12	32	235	96
AEAD_RIJNDAEL_GCM_SST_14	32	219	112

Common parameters for the six AEAD instances:

• N_MIN = N_MAX (minimum and maximum size of the nonce) is 12 octets for AES, while for Rijndael-256, it is 28 bytes.
• C_MAX (maximum size of the ciphertext and tag) is P_MAX + tag_length (in bytes)
• Q_MAX (maximum number of invocations of the encryption function) is 2³² for AES-GCM-SST, while for Rijndael-GCM-SST, it is 2⁸⁸.
• V_MAX (maximum number of invocations of the decryption function) is 2⁴⁸ for AES-GCM-SST, while for Rijndael-GCM-SST, it is 2⁸⁸.

The maximum size of the plaintext (P_MAX) and the maximum size of the associated data (A_MAX) have been lowered from GCM . To enable forgery probability close to ideal, even with maximum size plaintexts and associated data, we set P_MAX = A_MAX = min(2^{131 - tag_length}, 2³⁶ - 48). Protocols that employ GCM-SST MAY impose stricter limits on P_MAX and A_MAX. Just like , AES-GCM-SST and Rijndael-GCM-SST only allow a fixed nonce length (N_MIN = N_MAX) of 96 bits and 224 bits, respectively. For the AEAD algorithms in the worst-case forgery probability is bounded by ≈ 2^-tag_length . This is true for all allowed plaintext and associated data lengths. The V_MAX constraint ensures that the Bernstein bound factor is δ ≈ 1 for AES-GCM-SST in protocols where ℓ ≈ 2¹², such as QUIC , and always δ ≈ 1 for Rijndael-GCM-SST. In addition to restricting the Bernstein bound factor, the Q_MAX constraint establishes a minimum threshold for the complexity of distinguishing attacks. Since encryption and decryption queries play an equivalent role in the Bernstein bound, it follows that Q_MAX ≤ V_MAX. Protocols that employ GCM-SST MAY impose stricter limits on Q_MAX and V_MAX. Protocols utilizing AES-GCM-SST MUST enforce stricter limits P_MAX, A_MAX, Q_MAX, and/or V_MAX to ensure that (P_MAX + A_MAX) ⋅ (Q_MAX + V_MAX) ⪅ 2⁶⁶. This ensures that δ ≈ 1. Refer to Sections , , and for further details.

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 H and Q 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 . Inoue et al. 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 and MUST be used with replay protection. Reuse of nonces in successful encryption and decryption function calls enable universal forgery . For a given tag length, GCM-SST has strictly better security properties than GCM. GCM allows universal forgery with lower complexity than GCM-SST, even when nonces are not reused. Implementations SHOULD add randomness to the nonce by XORing a unique number like a sequence number with a per-key random secret salt of the same length as the nonce. This significantly improves security against precomputation attacks and multi-key attacks and is for example implemented 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-256-GCM-SST. This specification does not allow the use of GCM-SST in multicast or broadcast scenarios. While GCM-SST offers better security properties than GCM for a given tag length in such contexts, it does not behave like an ideal MAC.

Integrity The GCM-SST tag_length SHOULD NOT be smaller than 4 bytes and cannot be larger than 16 bytes. Let ℓ = (P_MAX + A_MAX) / 16 + 1. When tag_length < 128 - log2(ℓ) bits, the worst-case forgery probability is bounded by ≈ 2^-tag_length . The tags in the AEAD algorithms listed in therefore have an almost perfect security level. This is significantly better than GCM where the security level is only tag_length - log2(ℓ) bits . For a graph of the forgery probability, refer to Fig. 3 in . As one can note, for 128-bit tags and long messages, the forgery probability is not close to ideal and similar to 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. The expected number of forgeries, when tag_length < 128 - log2(ℓ) bits, depends on the keystream generator. For an ideal keystream generator, the expected number of forgeries is ≈ v / 2^tag_length, where v is the number of decryption queries, which is ideal. For AES-GCM-SST, the expected number of forgeries is ≈ δ₁₂₈ ⋅ v / 2^tag_length, where the Bernstein bound factor δ_b ⪅ 1 + (q + v)² ⋅ ℓ² / 2^b+1, which is ideal when δ₁₂₈ ≈ 1. This far outperforms AES-GCM, where the expected number of forgeries is ≈ δ₁₂₈ ⋅ v² ⋅ ℓ / 2^tag_length+1. For Rijndael-GCM-SST, the expected number of forgeries is ≈ δ₂₅₆ ⋅ v / 2^tag_length ≈ v / 2^tag_length, which is ideal. 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 δ ≈ 1. Achieving a comparable level of security with GCM, CCM, or Poly1305 is nearly impossible.

Confidentiality The confidentiality offered by AES-GCM-SST against passive attackers is equal to AES-GCM and given by the birthday bound. Regardless of key length, an attacker can mount a distinguishing attack with a complexity of approximately 2¹²⁹ / q, where q is the number of invocations of the AES encryption function. 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²⁵⁷ / q, where q is the number of invocations of the Rijndael-256 encryption function. While Rijndael-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 or other alternatives such as . The confidentiality offered by AES-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 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 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 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.

Replay Protection 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 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 while exposing the system to denial-of-service attacks .

Comparison with ChaCha20-Poly1305 and AES-GCM compares the integrity of AES-GCM-SST, ChaCha20-Poly1305 , and AES-GCM in unicast security protocols with replay protection, where v represents the number of decryption queries. In Poly1305 and GCM, the forgery probability depends on ℓ = (P_MAX + A_MAX) / 16 + 1. In AES-based algorithms, the Bernstein bound introduces a factor δ ⪅ 1 + (q + v)² ⋅ ℓ² / 2¹²⁹. GCM-SST requires δ ≈ 1, a property not mandated by GCM. Notably, GCM does not provide any reforgeability resistance, which significantly increases the expected number of forgeries. Refer to , , and for further details. Comparison between AES-GCM-SST, ChaCha20-Poly1305, and AES-GCM in unicast security protocols with replay protection. v is the number of decryption queries, ℓ is the maximum length of plaintext and associated data, measured in 128-bit chunks, and δ is the Bernstein bound factor.

Name	Forgery probability before first forgery	Forgery probability after first forgery	Expected number of forgeries
GCM_SST_14	1 / 2112	1 / 2112	v / 2112
GCM_SST_12	1 / 296	1 / 296	v / 296
POLY1305	ℓ / 2103	ℓ / 2103	v ⋅ ℓ / 2103
GCM	ℓ / 2128	1	δ ⋅ v2 ⋅ ℓ / 2129

compares the integrity of AES-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 AES-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 AES-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 is equivalent to that of an ideal MAC with a length of 64.4 bits. The effective tag length of AES-GCM in QUIC is 117 - log2(δ ⋅ v). Comparison between AES-GCM-SST, ChaCha20-Poly1305, and AES-GCM in unicast QUIC, where the maximum packet size is 65536 bytes.

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

IANA Considerations IANA is requested to assign the entries in the first column of to the "AEAD Algorithms" registry under the "Authenticated Encryption with Associated Data (AEAD) Parameters" heading with this document as 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] 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. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). 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. 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)

Change Log Changes from -14 to -15:

• Added 48-bit tags after feedback from media people.
• Added comparison to AEGIS in pure hardware based on Scott Fluhrer's analysis
• Changed "acceptable level" to "minimum threshold" as it can be discussed if 64 bit security is acceptable.
• Added requirement that security protocols using AES-GCM-SST MUST enforce limits to ensure that δ ≈ 1.
• Added that this specification does not allow use in multicast or broadcast. This simplify security considerations.
• Editorial changes

Changes from -13 to -14:

• Explained the formatting of L as well as why replay protection after decryption may be used.
• Updated link to NIST's plans to standardize Rijndael-256 and aligned the name with NIST
• Aligned test vector tag length and terminology with the rest of the specification
• Editorial changes

Changes from -12 to -13:

• Changed name to Strong Secure Tags to better illustrate that GCM-SST is intended to improve security for all tag lengths.
• Editorial changes

Changes from -11 to -12:

• Introduced Q_MAX and V_MAX as formal names for the invocation constraints.
• Described that masking is important to mitigate weak keys.
• Improved and expanded the section comparing GCM-SST with Poly1305 and GCM.
• Editorial changes including subsections in the security considerations.

Changes from -10 to -11:

• Added that protocols can impose stricter limits on P_MAX and A_MAX
• Added constraints on the number of decryption queries v
• More info on replay protection implementation
• More info on nonce constructions
• Introduced the Bernstein bound factor δ instead of just assuming that δ < 2
• Clarified differences between GCM-SST with different keystream generators (ideal, AES, Rijndael)
• Made it clearer that Table 1 is for unicast security protocols with replay protection and that Poly1305 is keyed with ChaCha20.
• Editorial changes including RFC 2119 terminology

Changes from -09 to -10:

• Corrected some probabilities that were off by a factor 2
• Editorial changes.

Changes from -07 to -09:

• Changed replay requirements to allow replay protection after decryption to align with protocols like QUIC and DTLS 1.3.
• Added a comparison between GCM_SST_14, GCM_SST_12, GCM_16, POLY1305 in protocols like QUIC
• Added text on the importance of behaving like an ideal MAC
• Consideration on replay protection mechanisms
• Added text and alternative implementations borrowed from NIST
• Added constraints of 2^32 encryption invocations aligning with NIST
• Added text explaining that GCM-SST offer strictly better security than GCM and 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.

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 expected 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 , , , , , , and for their valuable comments and feedback. Some of the formatting and text were inspired by and borrowed from .