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

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

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 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 [Bellare], such as QUIC [RFC9001], implement replay protection after decryption to mitigate timing side-channel attacks.¶

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

4.1. 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 [AES]. Big-endian counters align with existing implementations of counter mode.¶

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

We define twelve AEAD instances, in the format of [RFC5116], that use AES-GCM-SST and Rijndael-GCM-SST with tag lengths of 32, 64, 96, and 112 bits. The key length and tag length are related to different security properties, and an application encrypting audio packets with small tags might require 256-bit confidentiality.¶

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 [RFC5116]. 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). Security protocols employing GCM-SST MAY impose stricter limits on P_MAX and A_MAX. Just like [RFC5116], AES-GCM-SST and Rijndael-GCM-SST only allow a fixed nonce length (N_MIN = N_MAX) of 96-bit and 224-bits respectively. For the AEAD algorithms in Table 1 the worst-case forgery probability is bounded by ≈ 2^-tag_length [Nyberg]. 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 [RFC9000], and always δ ≈ 1 for Rijndael-GCM-SST. In addition to restricting the Bernstein bound factor, the Q_MAX constraint also keeps the attack complexity of distinguishing attacks at an acceptable level. Since encryption and decryption queries play an equivalent role in the Bernstein bound, it follows that Q_MAX ≤ V_MAX. Security protocols employing GCM-SST MAY impose stricter limits on Q_MAX and V_MAX. Refer to Section 5 for further details.¶

5.1. 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 [Nyberg]. The tags in the AEAD algorithms listed in Section 4.3 therefore have an almost perfect security level. This is significantly better than GCM where the security level is only tag_length - log2(ℓ) bits [GCM]. For a graph of the forgery probability, refer to Fig. 3 in [Inoue]. As one can note, for 128-bit tags and long messages, the forgery probability is not close to ideal and similar to GCM [GCM]. If tag verification fails, the plaintext and expected_tag MUST NOT be given as output. In GCM-SST, the full_tag is independent of the specified tag length unless the application explicitly incorporates tag length into the keystream or the nonce.¶

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 near-ideal. 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 [Iwata], [Inoue], [Bernstein], and [Multiple]. BSI states that an ideal MAC with a 96-bit tag length is considered acceptable for most applications [BSI], a requirement that AES-GCM-SST with 96-bit tags satisfies when δ ≈ 1. Achieving a comparable level of security with GCM, CCM, or Poly1305 is nearly impossible.¶

5.2. Confidentiality

The confidentiality offered by AES-GCM-SST against passive attackers is equal to AES-GCM [GCM] and given by the birthday bound. Regardless of key length, an attacker can mount a distinguishing attack with a complexity of approximately 2¹²⁹ / 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 [Degabriele] or other alternatives such as [SMAC].¶

The confidentiality offered by AES-GCM-SST against active attackers is directly linked to the forgery probability. Depending on the protocol and application, forgeries 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 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.¶

5.4. 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 [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 while exposing the system to denial-of-service attacks [Robust].¶

5.5. Comparison with ChaCha20-Poly1305 and AES-GCM

Table 2 compares the integrity of AES-GCM-SST, ChaCha20-Poly1305 [RFC7539], and AES-GCM [RFC5116] 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¹²⁹. Notably, GCM does not provide any reforgeability resistance, which significantly increases the expected number of forgeries. Refer to [Procter], [Iwata], and [Multiple] for further details.¶

Table 3 compares the integrity of AES-GCM-SST, ChaCha20-Poly1305 [RFC7539], 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 [RFC7539] and AES-GCM [RFC5116], 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 [RFC9001], 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).¶

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

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

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

[Bellare]

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

[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, February 2024, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html>.

[Collision]

Preuß Mattsson, J., "Collision Attacks on Galois/Counter Mode (GCM)", September 2024, <https://eprint.iacr.org/2021/236>.

[Comments38B]

NIST, "Public Comments on SP 800-38B", September 2024, <https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-38b-initial-public-comments-2024.pdf>.

[Degabriele]

Degabriele, J., Gilcher, J., Govinden, J., and K. Paterson, "Universal Hash Designs for an Accordion Mode", June 2024, <https://csrc.nist.gov/csrc/media/Presentations/2024/universal-hash-designs-for-an-accordion-mode/images-media/sess-7-degabriele-acm-workshop-2024.pdf>.

[Ducker]

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

[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://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf>.

[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.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-14, 12 December 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aegis-aead-14>.

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

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

[MoQ]

IETF, "Media Over QUIC", September 2022, <https://datatracker.ietf.org/wg/moq/about/>.

[Multiple]

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

[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", September 2024, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3196>.

[Plans]

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

[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 akob 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>.

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

[RFC7539]

Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <https://www.rfc-editor.org/rfc/rfc7539>.

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

[Rogaway]

Rogaway, P., "Evaluation of Some Blockcipher Modes of Operation", February 2011, <https://www.cryptrec.go.jp/exreport/cryptrec-ex-2012-2010r1.pdf>.

[SAGE23]

ETSI SAGE, "Specification of the 256-bit air interface algorithms", February 2023, <https://www.3gpp.org/ftp/TSG_SA/WG3_Security/TSGS3_110_Athens/docs/S3-230642.zip>.

[SAGE24]

ETSI SAGE, "Version 2.0 of 256-bit Confidentiality and Integrity Algorithms for the Air Interface", August 2024, <https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_117_Maastricht/docs/S3-243394.zip>.

[Sec5G]

3GPP TS 33 501, "Security architecture and procedures for 5G System", September 2024, <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]

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

[SST1]

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

[SST2]

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/Presentations/2023/galois-counter-mode-with-secure-short-tags/images-media/sess-5-mattsson-bcm-workshop-2023.pdf>.

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

[WID23]

3GPP, "New WID on Milenage-256 algorithm", November 2023, <https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_113_Chicago/Docs/S3-235072.zip>.

[WID24]

3GPP, "New WID on Addition of 256-bit security Algorithms", March 2024, <https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_103_Maastricht_2024-03/Docs/SP-240476.zip>.

[ZUC]

ZUC Design Team, "An Addendum to the ZUC-256 Stream Cipher", September 2024, <https://eprint.iacr.org/2021/1439>.

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 }
         Q = { 03 13 63 96 74 be fa 86 4d fa fb 80 36 b7 a0 3c }
         M = { 9b 1d 49 ea 42 b0 0a ec b0 bc eb 8d d0 ef c2 b9 }

         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 }
         Q = { 3b fd 00 96 25 84 2a 86 65 71 a4 66 e5 62 05 92 }
         M = { 9e 6c 98 3e e0 6c 1a ab c8 99 b7 8d 57 32 0a f5 }
         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 }
        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 }
         Q = { af 7f 54 00 16 aa b8 bc 91 56 d9 d1 83 59 cc e5 }
         M = { b3 35 31 c0 e9 6f 4a 03 2a 33 8e ec 12 99 3e 68 }

         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 }
        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 }
        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 }
        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 }
        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 }
        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 }
         Q = { 32 69 75 a3 3a ff ae ac af a8 fb d1 bd 62 66 95 }
         M = { 59 48 44 80 b6 cd 59 06 69 27 5e 7d 81 4a d1 74 }
         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 }