Does the AES-GCM specification require the tag-size to be bound to the GCM context?

Question

Does GCM spec (NIST SP 800-38D) require tag-size to be fixed for an instance of GCM algorithm (which usually fixes a specific GCM key)?

Asked differently, is the following a legitimate adherence to GCM spec?

There is a discussion going on on GitHub - perhaps knowledgeable folks could comment.

// pseudocode
var one_gcm = new AesGcm(key); key is a legit key of 16/24/32 bytes
var (ciphertext, tag16) = one_gcm.Encrypt(plaintext); // produces 16-byte tag
var truncated_tag12 = tag16.Slice(0,12); // truncating the tag to 12 bytes
var decrypted = one_gcm.Decrypt(ciphertext, truncated_tag12); // this is successful

Answer 1

Does GCM spec (NIST SP 800-38D) require tag-size to be fixed for an instance of GCM algorithm (which usually fixes a specific GCM key)?

Yes.

---

The tag length $t$ is considered a pre-requisite in NIST SP 800-38D section 7.

It does say in at the top of NIST SP 800-38D section 7 that:

however, some of the prerequisites may also be regarded as (varying) input.

But after that, it explicitly mentions, as prerequisite in 7.1 (GCM encryption) and 7.2 (GCM decryption):

• supported tag length t associated with the key.

This directly answers your question in my opinion.

---

The security of GCM depends a lot on the size of the tag, and the security considerations for short tag lengths in NIST SP 800-38D should be taken into account. Both sections B and C of the appendices of NIST SP 800-38D are about authentication and using small tag sizes.

Note that you cannot fully trust to have the tag size authenticated by the tag itself, i.e. as part of the Additional Authenticated Data; if the construction is vulnerable then an attacker could create a small valid tag for a message that includes the tag size.

Generally then, you have to either use a static size for the tag $t$ or you need to securely negotiate the tag size beforehand.

Answer 2

NIST SP 800-38D says:

The bit length of the tag, denoted t, is a security parameter, as discussed in Appendix B. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32; guidance for the use of these two tag lengths, including requirements on the length of the input data and the lifetime of the key in these cases, is given in Appendix C.

An implementation shall not support values for t that are different from the seven choices in the preceding paragraph. An implementation may restrict its support to as few as one of these values. A single, fixed value for t from among the supported choices shall be associated with each key.

Thus, the tag clearly doesn't have to be 128 bits, although it should be. However, 'a single fixed value' means you shouldn't use different tag lengths with the same key. Otherwise, an attacker may be able to truncate the tag, resulting in a reduction in security. For comparison, the RFC for ChaCha20-Poly1305 only allows 128-bit tags.

Therefore, you shouldn't do what that pseudocode does, but I'm guessing the argument is that it's up to the application to enforce this, not the cryptographic library if they want to support multiple tag lengths. That's frankly poor API design though.