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

1.1. Background and Motivation

AES in Galois Counter Mode (AES-GCM) [GCM] is a widely deployed Authenticated Encryption with Associated Data (AEAD) algorithm [RFC5116], valued for its performance in hardware and software, and its provable security. During NIST standardization, Ferguson identified two weaknesses in GCM's authentication function [Ferguson]. 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. [Nyberg] showed that small, theoretically grounded changes would mitigate these weaknesses, but NIST instead imposed ad hoc restrictions for short tags. Mattsson et al. [Mattsson] 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 [Revise], 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 [GCM] offers only a forgery probability of 2^-39, and with 128-bit tags in QUIC [RFC9001], 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 [Reforge][AEZ].¶

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 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 [I-D.ietf-moq-transport] and much slower constructions such as AES-CTR with HMAC [RFC3711][RFC9605]. 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 [RFC5116] achieves near-ideal probabilities with short tags but at a performance penalty relative to GCM.¶

1.2. 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 [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 [RFC8452]. 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 [RFC8446], QUIC [RFC9000], SRTP [RFC3711], and PDCP [PDCP]. In unicast settings with replay protection, GCM-SST's authentication tag behaves as an ideal MAC with full reforgeability resistance. Compared to Poly1305 [RFC8439] and GCM [RFC5116], 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 [GCM-Update][Gueron].¶

This document also registers GCM-SST instances using AES [AES] and Rijndael with 256-bit keys and blocks (Rijndael-256) [Rijndael] 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 [Milenage-256] and is planned for NIST standardization [AES-WIDE]. On modern x86 platforms with AES-NI and VAES instructions, Rijndael-256 performs efficiently [Drucker]. Compared to AEGIS [I-D.irtf-cfrg-aegis-aead], 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 [NCA4], AES-256 [NCA5], and ZUC-256 [NCA6] in 3GPP TS 35.240–35.248. Security proofs for GCM-SST in single- and multi-key settings are provided by Inoue et al. [Inoue] and Naito et al. [Naito].¶

Section 3 specifies GCM-SST, Section 4 registers AEAD algorithms using AES and Rijndael-256, and Section 5 discusses security considerations.¶

3.1. 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.¶

3.2. 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 [Bellare19], such as QUIC [RFC9001], 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).¶

3.3. 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 .¶

3.4. Usage Limits

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. Usage limits for a GCM-SST instance MUST be chosen to achieve this property in unicast settings with replay protection, and are therefore more restrictive than the corresponding limits for GCM [RFC5116].¶

To ensure that v / 2^t dominates the integrity advantage [Inoue] for all permitted plaintext and associated data lengths, an instance MUST ensure:¶

• ℓ ≪ 2^{128 - t} .¶

This ensures that the term v ⋅ ℓ / 2¹²⁸ is negligible. If the keystream generator is a Pseudo-Random Function (PRF), this condition is sufficient to satisfy E(F) ≈ v / 2^t. If the keystream generator is a Pseudo-Random Permutation (PRP) in counter mode, it is sufficient to satisfy E(F) ≈ δ ⋅ v / 2^t, where δ is the Bernstein bound factor [Bernstein][Iwata].¶

Instances using a block cipher in counter mode MUST ensure:¶

• Q_MAX ⋅ P_MAX ≤ 2^b/2-5 ⋅ b / 8 .¶

This aligns with the European [ACM] recommendation of limiting the number of block-cipher invocations to 2^b/2-5. In addition to ensuring δ ≈ 1, the requirement establishes a minimum complexity for distinguishing attacks and an upper bound on the fraction of plaintext bits recoverable by an attacker. This ensures that an attacker cannot recover more than ≈ 0.0007 bits across all plaintexts [Entropy] 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 [RFC4253][ANSSI].¶

4.1. 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 [AES]. The use of big-endian counters aligns with existing AES counter mode implementations.¶

4.2. 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 [Rijndael].¶

4.3. AEAD Instances and Constraints

Nine AEAD algorithm instances are defined below, following the format of [RFC5116]. These instances use AES-GCM-SST or Rijndael-GCM-SST with tag lengths of 48, 96, or 112 bits.¶

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 [RFC5116].¶

To ensure that v / 2^t is the dominant term in the integrity advantage [Inoue] 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.¶

For AES, the 128-bit block size implies that achieving δ ≈ 1 requires balancing the constraints on Q_MAX and P_MAX. To ensure that the Bernstein bound factor [Bernstein][Iwata] 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 ⪅ 2⁵⁹ .¶

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 [ACM] 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 [Entropy] 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 [RFC4253][ANSSI].¶

5.1. 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 [Nyberg][Inoue]. The tags in the AEAD algorithms listed in Section 4.3 therefore achieve near-ideal forgery probabilities. This is a significant improvement over GCM [GCM], where the forgery probability is bounded by ⪅ δ ⋅ ℓ / 2^t [GCM][Iwata]. For a graph of the forgery probability assuming δ ≈ 1, see Fig. 3 in [Inoue]. 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 Section 4.3, AES-GCM-SST and Rijndael-GCM-SST achieve this ideal. AES-GCM-SST significantly outperforms AES-GCM [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 [Iwata], [Niwa], [Inoue], [Naito], and [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-bit tags satisfies when ℓ ⪅ 2³² and δ ≈ 1. Achieving a comparable level of security with GCM, CCM, or Poly1305 is nearly impossible.¶

5.2. 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 [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 [Impossible] and Leurent and Sibleyras [Difference] 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 [Entropy] demonstrated that an attacker cannot recover more than ≈ σ² / 2^b bits of the plaintext. Given the constraints outlined in Section 4.3, 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 [Maximov][Degabriele] or other alternatives such as [SMAC].¶

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.¶

5.3. 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.¶

5.4. 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 [RFC4303] and [RFC6479]. 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 [Robust].¶

5.5. Comparison with ChaCha20-Poly1305 and AES-GCM

Table 2 compares the integrity of GCM-SST, ChaCha20-Poly1305 [RFC8439], and AES-GCM [RFC5116] 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 [Procter], [Iwata], and [Multiple] for further details.¶

Table 3 compares the integrity of GCM-SST, ChaCha20-Poly1305 [RFC8439], and AES-GCM [RFC5116] in unicast QUIC [RFC9000][RFC9001], 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 [RFC8439] and AES-GCM [RFC5116], 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 [RFC9001], the expected number of forgeries for AES-GCM exceeds that of an ideal 65-bit MAC.¶

Table 4 compares the confidentiality of Rijndael-GCM-SST, AES-256-GCM-SST, SNOW 5G-GCM-SST, and ChaCha20-Poly1305 [RFC8439], 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 [Entropy].¶

5.6. 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.¶

7.1. Normative References

[AES]

"Advanced Encryption Standard (AES)", NIST Federal Information Processing Standards Publication 197, May 2023, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5116]

McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/rfc/rfc5116>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8452]

Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, <https://www.rfc-editor.org/rfc/rfc8452>.

[Rijndael]

Joan Daemen and Vincent Rijmen, "AES Proposal: Rijndael", September 2003, <https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/aes-development/rijndael-ammended.pdf>.

7.2. Informative References

[Accordions]

NIST, "NIST Launches Development of Cryptographic Accordions", June 2025, <https://csrc.nist.gov/pubs/sp/800/197/a/iprd>.

[ACM]

"Agreed Cryptographic Mechanisms", April 2025, <https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en>.

[AES-WIDE]

NIST, "NIST Proposes to Standardize a Wider Variant of AES", December 2024, <https://csrc.nist.gov/pubs/sp/800/197/iprd>.

[AEZ]

Viet Tung Hoang, Ted Krovetz, and Phillip Rogaway, "Robust Authenticated-Encryption: AEZ and the Problem that it Solves", March 2017, <https://eprint.iacr.org/2014/793.pdf>.

[ANSSI]

"Recommendations for securing networks with IPsec", August 2015, <https://messervices.cyber.gouv.fr/documents-guides/NT_IPsec_EN.pdf>.

[Ascon]

Meltem Sönmez Turan, Kerry A McKay, Donghoon Chang, Jinkeon Kang, and John Kelsey, "Ascon-Based Lightweight Cryptography Standards for Constrained Devices", NIST Special Publication 800-232 Initial Public Draft, November 2024, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-232.ipd.pdf>.

[Bellare17]

Bellare, M. and B. Tackmann, "The Multi-User Security of Authenticated Encryption: AES-GCM in TLS 1.3", November 2017, <https://eprint.iacr.org/2016/564.pdf>.

[Bellare19]

Mihir Bellare, Ruth Ng, and Björn Tackmann, "Nonces are Noticed: AEAD Revisited", November 2019, <https://eprint.iacr.org/2019/624.pdf>.

[Bernstein]

Daniel J Bernstein, "Stronger Security Bounds for Permutations", March 2005, <https://cr.yp.to/antiforgery/permutations-20050323.pdf>.

[BSI]

"Cryptographic Mechanisms Recommendations and Key Lengths", BSI Technical Guideline TR-02102-1, January 2026, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html>.

[Campagna]

Campagna, M., Maximov, A., and J. Preuß Mattsson, "Galois Counter Mode with Strong Secure Tags (GCM-SST)", October 2023, <https://csrc.nist.gov/csrc/media/Events/2023/third-workshop-on-block-cipher-modes-of-operation/documents/accepted-papers/Galois%20Counter%20Mode%20with%20Secure%20Short%20Tags.pdf>.

[Degabriele]

Degabriele, J., Gilcher, J., Govinden, J., and K. Paterson, "SoK: Efficient Design and Implementation of Polynomial Hash Functions over Prime Fields", May 2024, <https://doi.org/10.3929/ethz-b-000654260>.

[Difference]

Gaëtan Leurent and Ferdinand Sibleyras, "The Missing Difference Problem, and Its Applications to Counter Mode Encryption", March 2018, <https://link.springer.com/chapter/10.1007/978-3-319-78375-8_24>.

[Drucker]

Nir Drucker and Shay Gueron, "Software Optimization of Rijndael for Modern x86-64 Platforms", May 2022, <https://rd.springer.com/chapter/10.1007/978-3-030-97652-1_18>.

[EIA3]

ETSI SAGE, "128-EEA3 and 128-EIA3 Specification", January 2019, <https://www.gsma.com/solutions-and-impact/technologies/security/wp-content/uploads/2019/05/EEA3_EIA3_specification_v1_8.pdf>.

[Entropy]

Preuß Mattsson, J., "Collision-Based Attacks on Block Cipher Modes - Exploiting Collisions and Their Absence", February 2025, <https://eprint.iacr.org/2024/1111.pdf>.

[Ferguson]

Ferguson, N., "Authentication weaknesses in GCM", May 2005, <https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/Ferguson2.pdf>.

[GCM]

Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.

[GCM-Update]

McGrew, D. and J. Viega, "GCM Update", May 2005, <https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/gcm-update.pdf>.

[Gueron]

Gueron, S., "Constructions based on the AES Round and Polynomial Multiplication that are Efficient on Modern Processor Architectures", October 2023, <https://csrc.nist.gov/csrc/media/Presentations/2023/constructions-based-on-the-aes-round/images-media/sess-5-gueron-bcm-workshop-2023.pdf>.

[I-D.ietf-moq-transport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-18, 12 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-18>.

[I-D.irtf-cfrg-aegis-aead]

Denis, F. and S. Lucas, "The AEGIS Family of Authenticated Encryption Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aegis-aead-18, 5 October 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aegis-aead-18>.

[Impossible]

David McGrew, "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes", November 2012, <https://eprint.iacr.org/2012/623.pdf>.

[Inoue]

Akiko Inoue, Ashwin Jha, Bart Mennink, and Kazuhiko Minematsu, "Generic Security of GCM-SST", November 2024, <https://eprint.iacr.org/2024/1928.pdf>.

[Iwata]

Tetsu Iwata, Keisuke Ohashi, and Kazuhiko Minematsu, "Breaking and Repairing GCM Security Proofs", August 2012, <https://eprint.iacr.org/2012/438.pdf>.

[Joux]

Joux, A., "Authentication Failures in NIST version of GCM", April 2006, <https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf>.

[Lindell]

Lindell, Y., "Comment on AES-GCM-SST", May 2024, <https://mailarchive.ietf.org/arch/browse/cfrg/?gbt=1&index=cWpv0QgX2ltkWhtd3R9pEW7E1CA>.

[Mattsson]

Mattsson, J. and M. Westerlund, "Authentication Key Recovery on Galois/Counter Mode (GCM)", May 2015, <https://eprint.iacr.org/2015/477.pdf>.

[Maximov]

Maximov, A. and H. Sjöberg, "On Fast Multiplication in Binary Finite Fields and Optimal Primitive Polynomials over GF(2)", September 2017, <https://eprint.iacr.org/2017/889.pdf>.

[Milenage-256]

3GPP, "Specification of the MILENAGE-256 algorithm set", January 2025, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4244>.

[Multiple]

David McGrew and Scott Fluhrer, "Multiple Forgery Attacks Against Message Authentication Codes", May 2005, <https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/multi-forge-01.pdf>.

[Naito]

Yusuke Naito, Yu Sasaki, and Takeshi Sugawara, "The Multi-user Security of GCM-SST and Further Enhancements", October 2025, <https://doi.org/10.1007/978-3-032-08124-7_3>.

[NCA4]

3GPP, "Specification of the Snow 5G based 256-bits algorithm set", March 2026, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4220>.

[NCA5]

3GPP, "Specification of the AES based 256-bits algorithm set", March 2026, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4221>.

[NCA6]

3GPP, "Specification of the ZUC based 256-bits algorithm set", March 2026, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4224>.

[Niwa]

Yuichi Niwa, Keisuke Ohashi, Kazuhiko Minematsu, and Tetsu Iwata, "GCM Security Bounds Reconsidered", March 2015, <https://eprint.iacr.org/2015/214.pdf>.

[NMR]

Rogaway, P. and T. Shrimpton, "Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem", August 2007, <https://eprint.iacr.org/2006/221.pdf>.

[NMRL]

Ashur, T., Dunkelman, O., and A. Luykx, "Boosting Authenticated Encryption Robustness with Minimal Modifications", August 2007, <https://doi.org/10.1007/978-3-319-63697-9_1>.

[Nyberg]

Nyberg, K., Gilbert, H., and M. Robshaw, "Galois MAC with forgery probability close to ideal", June 2005, <https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/general-comments/papers/Nyberg_Gilbert_and_Robshaw.pdf>.

[PDCP]

3GPP TS 38 323, "NR; Packet Data Convergence Protocol (PDCP) specification", January 2026, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3196>.

[Procter]

Gordon Procter, "A Security Analysis of the Composition of ChaCha20 and Poly1305", August 2014, <https://eprint.iacr.org/2014/613.pdf>.

[Reforge]

Christian Forler, Eik List, Stefan Lucks, and Jakob Wenzel, "Reforgeability of Authenticated Encryption Schemes", April 2017, <https://eprint.iacr.org/2017/332.pdf>.

[Revise]

NIST, "Announcement of Proposal to Revise SP 800-38D", August 2023, <https://csrc.nist.gov/news/2023/proposal-to-revise-sp-800-38d>.

[RFC3711]

Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/rfc/rfc3711>.

[RFC4253]

Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/rfc/rfc4253>.

[RFC4303]

Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/rfc/rfc4303>.

[RFC6479]

Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm without Bit Shifting", RFC 6479, DOI 10.17487/RFC6479, January 2012, <https://www.rfc-editor.org/rfc/rfc6479>.

[RFC8439]

Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/rfc/rfc8439>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8613]

Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/rfc/rfc8613>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.

[RFC9605]

Omara, E., Uberti, J., Murillo, S. G., Barnes, R., Ed., and Y. Fablet, "Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media", RFC 9605, DOI 10.17487/RFC9605, August 2024, <https://www.rfc-editor.org/rfc/rfc9605>.

[Robust]

Fischlin, M., Günther, F., and C. Janson, "Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3", January 2024, <https://link.springer.com/article/10.1007/s00145-023-09489-9>.

[Sec5G]

3GPP TS 33 501, "Security architecture and procedures for 5G System", March 2026, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169>.

[SMAC]

Wang, D., Maximov, A., Ekdahl, P., and T. Johansson, "A new stand-alone MAC construct called SMAC", June 2024, <https://eprint.iacr.org/2024/819>.

[SNOW-Axn]

Wang, D., Maximov, A., Ekdahl, P., and T. Johansson, "Pushing to the limits: SNOW-Axn – a fast AEAD stream cipher in aggregated mode", May 2026, <https://cic.iacr.org/p/3/1/31/pdf>.

[SNOW-Vi]

Ekdahl, P., Johansson, T., Maximov, A., and J. Yang, "SNOW-Vi: an extreme performance variant of SNOW-V for lower grade CPUs", March 2021, <https://eprint.iacr.org/2021/236>.

[UIA2]

ETSI SAGE, "UEA2 and UIA2 Specification", March 2009, <https://www.gsma.com/solutions-and-impact/technologies/security/wp-content/uploads/2019/05/uea2uia2d1v21.pdf>.

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

         K = { 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f }
         N = { 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 }
       H_2 = { 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 }

         A = { }
         P = { }
         L = { 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 42 b0 0a ec b0 bc eb 8d }
        ct = { }

         A = { 40 41 42 43 44 }
         P = { }
         L = { 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 d5 f3 08 a5 70 4e 2f d5 }
        ct = { }

         A = { }
         P = { 60 61 62 63 64 65 66 67 68 69 6a 6b }
         L = { 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 fd 1a 90 d9 81 8f cb 7b }
        ct = { 64 f0 5b ae 1e d2 40 3a 71 25 5e dd }

         A = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f }
         P = { 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 }
         L = { 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 0b 84 48 2c d0 14 c7 40 }
        ct = { 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 }

         A = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e }
         P = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 }
         L = { 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 11 43 ab e9 31 5a d7 eb }
        ct = { 64 f0 5b ae 1e d2 40 3a 71 25 5e dd 53 49 5c e1
               7d }

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

         K = { 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9 eb }
         N = { 9a 50 ee 40 78 36 fd 12 49 32 f6 9e }
         A = { 1f 03 5a 7d 09 38 25 1f 5d d4 cb fc 96 f5 45 3b
               13 0d }
         P = { 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 }
       H_2 = { 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 }
         L = { 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 }
        ct = { b8 65 d5 16 07 83 11 73 21 f5 6c b0 75 45 16 b3
               da 9d b8 09 }

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

         K = { 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 }
         N = { 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 }
       H_2 = { 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 }

         A = { }
         P = { }
         L = { 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 2a 33 8e ec }
        ct = { }

         A = { 40 41 42 43 44 }
         P = { }
         L = { 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 28 ff c3 17 }
        ct = { }

         A = { }
         P = { 60 61 62 63 64 65 66 67 68 69 6a 6b }
         L = { 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 48 bd 6f cc }
        ct = { fc 46 2d 34 a7 5b 22 62 4f d7 3b 27 }

         A = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f }
         P = { 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 }
         L = { 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 a5 a8 a2 8e }
        ct = { 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 }

         A = { 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e }
         P = { 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
               70 }
         L = { 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 64 ce fd 03 }
        ct = { fc 46 2d 34 a7 5b 22 62 4f d7 3b 27 84 de 10 51
               33 }

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

         K = { 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 }
         N = { 9a 50 ee 40 78 36 fd 12 49 32 f6 9e }
         A = { 1f 03 5a 7d 09 38 25 1f 5d d4 cb fc 96 f5 45 3b
               13 0d }
         P = { 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 }
       H_2 = { 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 }
         L = { 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 73 49 bf 3c }
        ct = { b5 c2 a4 07 f3 3e 99 88 de c1 2f 10 64 7b 3d 4f
               eb 8f f7 cc }