1
$\begingroup$

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
$\endgroup$
1
  • 1
    $\begingroup$ I've chimed in. I find that I had to criticize bartonjs because pointing to another horrid implementation of GCM (in OpenSSL) is not really helpful, but I do support the notion of going forward and using the new constructors proposed that include the tag size. Personally I don't like these "one-shot" libraries anyway. I do see the need to always verify the tag, but for e.g. file decryption, I would definitely want a streaming API. $\endgroup$
    – Maarten Bodewes
    Jul 15, 2022 at 12:39

2 Answers 2

3
$\begingroup$

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.

$\endgroup$
4
$\begingroup$

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.

$\endgroup$
1
  • 2
    $\begingroup$ It's also an obvious footgun. The application receives the tag from an untrusted ciphertext message and passes it to the library for validation, so it's perfectly reasonable for the application writer to expect the library to validate the length of the tag too. If the library expects the application to validate the length instead, there's a very high risk that nobody ends up validating the length, possibly allowing an attacker to forge messages using very short tags. $\endgroup$ Jul 15, 2022 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.