Date Published: June 1, 2026
Comments Due:
Email Questions to:
Planning Note (06/01/2026):
The use of "2nd Preliminary Draft" above simply indicates the current step in our publication development workflow. For this announcement, there is no actual draft document available. We are seeking feedback regarding the issues below, before creating an initial draft document of SP 800-38Dr1 (revision 1) that will eventually be posted for public comment.
Author(s)
National Institute of Standards and Technology
Announcement
As previously announced, NIST is revising Special Publication (SP) 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. In addition to revising the Galois/Counter Mode (GCM), NIST proposes to specify a wider variant, wGCM. wGCM operates on an underlying block cipher with 256-bit blocks, to support the Rijndael-256 variant of AES that NIST proposed for standardization.
NIST is preparing an initial set of parameters for wGCM and requests feedback on the efficiency and security trade-offs, including the following issues and questions:
1. Questions on GCM:
- The revision to GCM will remove support for authentication tags whose lengths are less than 96 bits. Which of the remaining tag sizes (i.e., 96, 104, 112, 120, or 128 bits) are needed for GCM? In particular, would tag sizes of 96 bits and 128 bits be sufficient for applications?
- GCM currently supports variable-length IVs by applying the internal hash function to generate a new, 96-bit IV value. Are variable-length IVs important for any applications?
2. Questions on wGCM:
- Would a limit of 264 wGCM invocations per key be sufficient?
- What authentication tag sizes should be specified for wGCM (e.g., 128, 192, or 256 bits) to support larger data limits than GCM? Is more than one tag size necessary?
- NIST proposes 192 bits as the default IV length for wGCM, devoting the remaining 64 bits of the IV block within wGCM to the message block counter for the GCTR encryption. Is there a need to support longer IVs in wGCM by applying the internal hash function, as in GCM?
- The deterministic IV construction for GCM defines a fixed field and an invocation field. For wGCM, NIST proposes to recommend a fixed field of 96 bits and an invocation field of 96 bits to promote interoperability. Are other options needed?
- The random IV construction for GCM defines a random field and a free field. For wGCM, if the number of invocations per key were limited to 264, and if 192 bits were specified for the random field, then the probability of an IV collision would be limited to 2-64. Is the free field useful/necessary for wGCM?
- Are these two 192-bit IV constructions sufficiently flexible, or should NIST consider adding other, comparably secure constructions?
- The natural generalization of the GCM hash function (i.e., GHASH) for wGCM would specify a suitable polynomial of degree 256 to define a hash function (called wide-GHASH) on 256-bit blocks. The output can be truncated as needed to obtain the appropriate tag size. Should NIST consider a different option for the hash function component of wGCM? For example, two instances of GHASH using independent 128-bit keys could be concatenated and truncated as needed. Since this option (called concat-GHASH) operates on 128-bit blocks, it would be more efficient than wide-GHASH. However, concat-GHASH cannot provide as much generic security assurance as wide-GHASH and would require much more restrictive usage bounds (i.e., smaller limits on total data, the message length, and invocations per key) for any given security target.
The public comment period is open through July 31, 2026. Comments can be submitted to [email protected] with “Comments on SP 800-38D revision” in the subject field. Comments received in response to this request will be posted on this page after the due date. Submitters' names and affiliations (when provided) will be included, while contact information will be removed.
Learn more about NIST’s cipher modes project.
Control Families
None selected
