NIST request for pre-draft comments on SP 800-38D

[Dworkin, Morris J. (Fed)]

FYI, on Monday NIST posted a request for public comments on the pending revision of SP 800-38D, especially on the development of a wide variant of Galois/Counter Mode, to support the eventual standardization of a 256-bit block cipher. Public comments were requested by July 31.

 

Morris Dworkin

on behalf of the NIST cipher modes team

[John Preuß Mattsson]

Hi Morris,

Ericsson provided the following comments
https://emanjon.github.io/NIST-comments/2026%20SP%20800-38D.pdf

John Preuß Mattsson
Expert Cryptographic Algorithms and Security Protocols, Ericsson

on behalf of the Ericsson Cryptography Team

[Jean Paul Degabriele]

Hi All,

Please find attached our comments regarding the design of wide-GHASH to be included as part of wGCM. Please let us know if further technical details, implementation results, or clarifications would be useful.

Best regards,

Jean Paul Degabriele, Jan Gilcher, Jérôme Govinden and Kenneth G. Paterson

[John Preuß Mattsson]

Hi all,

Jean and team, thanks for sharing. Looking forward to read [DGGP26] when published.

My colleague Alexander Maximov and I continued to think a lot about suitable polynomial hash function for Rijndael-256 and also implemented and benchmarked a lot of potential alternatives.

- We no longer believe in 1x^191 + x^120 + 1 and similar trinomials are the best choice, due to complications with data alignment, impacting software performance.
- We also implemented a (2^64)^3 tower field but it showed no speed gain versus a classical 2^192 field.
- Our current thinking is that the best wide GHASH field is GF(2^192) with the polynomial x^192 + x^7 + x^2 + x + 1 (x^192 + x^191 + x^190 + x^185 + 1 for POLYVAL style, POLYVAL-192). 192 aligns with the (64x64)-bit carry-less multiplier in PCLMULQDQ and PMULL.
- GF(2^256) with x^256 + x^10 + x^5 + x^2 + 1 is significantly slower and we do not see any practical need for such a large field.
- In a few weeks we will add Rijndael-256 with POLYVAL-192 to draft-mattsson-cfrg-aes-gcm-sst and resubmit that as draft-mattsson-cfrg-gcm-sst as it is no longer just AES.

Cheers,
John Preuß Mattsson

[Roberto Avanzi]

Hello

I have two comments and a question

1.

I would use the name MHASH for the "POLYVAL"-like function, where MHASH stands for Montgomery Hash.  It is not a new function, just GHASH computed in a different representation of the field, and it would be fitting to place the name of Montgomery, that first proposed that representation for computational purposes.

2.

For processing data in 256-bit chunks through the AXU, we could use

the primitive polynomial  p(X) = X^256 + X^254 + X^251 + X^246 + 1.

p', the inverse of p(X) modulo X^256 is X^254 + X^251 + X^246 + 1 .

I already proposed this polynomial in a paper.

For 192-bit security, p(x) = x^192 + x^191 + x^190 + x^185 + 1 is fine,

and its p' is also equal to its residue: p'(x) = x^191 + x^190 + x^185 + 1 .

3.

have you tried for your 192-bit code the short convolution with 6

multiplications?

  (a_2 Y^2 + a_1 Y + a_0)  (b_2 Y^2 + b_1 Y + b_0)
          =  a_2  b_2  Y^4 +
          + ((a_2 + a_1)  (b_2 + b_1) - a_1  b_1 - a_2  b_2)   Y^3 +
          + ((a_2 + a_0)  (b_2 + b_0) - a_0  b_0 + a_1  b_1 - a_2  b_2)   Y^2 +
          + ((a_1 + a_0)  (b_1 + b_0) - a_0  b_0 - a_1  b_1 )   Y

          + a_0  b_0

Y would be = x^64 and all a_i, b_i polynomials of degree up to 63.

 Roberto Avanzi

[John Preuß Mattsson]

Hi,

NIST has now published the public comments

https://csrc.nist.gov/files/pubs/sp/800/38/d/r1/2prd/docs/sp800-38Dr1-second-pre-draft-comments-received.pdf

Always a pleasure to read these. A few reflections on the comments.

------------------

Happy to see the attached paper, “Refinements of Authentication Key Recovery Attack against GCM” by Inoue, Iwata, and Minematsu, which significantly improves upon the work by Westerlund and me from 2016. The new paper provides further motivation for removing Appendix C.

I’m especially happy to see that the new authentication key recovery attack on GCM builds on earlier work on security proofs for GCM-SST.

------------------

"we are aware of established protocols that use shorter tags, including SRTP and cellular link-layer protocols used in 3GPP and 5G standards.

On this basis, NIST may wish to consider an initial step in SP 800-38Dr1 that deprecates, but does not yet disallow, shorter tags, with their eventual removal deferred to a future revision"

Short tags are essential for many use cases, but neither SRTP nor 5G uses GCM with short tags. 5G PDCP and NAS use AES-CMAC with 32-bit tags, while 6G will very likely use AES-GCM-SST with 64-bit tags. Both behave like ideal MACs. SRTP uses HMAC-SHA1 with 32- and 80-bit tags, as well as AES-GCM with 128-bit tags. AVTCORE is now discussing standardizing AES-GCM-SST with shorter tags for use with SRTP.

https://datatracker.ietf.org/meeting/126/materials/slides-126-avtcore-gcm-sst-in-srtp-01

While NIST should not disallow short CMAC, CCM, HMAC, or KMAC tags in general, as these behave like ideal MACs, there is no reason to allow short GCM tags, which do not behave like ideal MACs at all.

------------------

"short tags for 5G and adoption of GCM-SST, we are also aware of ongoing efforts to standardize this through the IETF (draft-mattson-cfrg-aes-gcm-sst-21)"

GCM-SST has already been standardized by 3GPP/ETSI SAGE in 3GPP TS 35.240–35.248. Ongoing efforts are focused on using GCM-SST in SRTP and QUIC, and the proposal received a very positive response at IETF 126.

------------------

"we strongly encourage NIST to consider adopting AES-GCM-SIV as a separate Special Publication"

I agree that a NIST-standardized MRAE mode would be useful. However, if NIST were to standardize MRAE modes based on HCTR2, as planned, would there still be a need for AES-GCM-SIV?

------------------

"As 2^-32 is current practice and is sufficient for GCM, we see no reason to lower it further."

I think it is debatable whether this reflects current practice and whether it is sufficient. Several large companies have stated in earlier comments to NIST that they do not use GCM with random nonces because of its low security.

If NIST continues to allow random nonces without NKD, I think this should be addressed through a general definition of what constitutes an acceptably low probability of success in single- and multi-user attacks. This belongs in a specification defining security levels, rather than in SP 800-38D.

Similarly, it would be useful for NIST security levels to define how much data should be considered a practical security concern. For example, EU ECCG ACM states that “Attacks requiring access to more than 2^64 blocks of data are thus not of practical concern.”

------------------

Cheers,
John Preuß Mattson

[Yaobin Shen]

Hi, 

I just want to share a simple attack against GCM/GMAC that can recover the hash key when the nonce is of a zero-length string. As NIST SP 800-38D explicitly requires the nonce to be of length at least 1 bit, this attack does not work for NIST SP 800-38D. Hence, it shows that this parameter choice in NIST SP 800-38D is reasonable. However, it looks like the ISO/IEC version of GCM and GMAC allows the nonce to be of a zero-length  string. 

Please find attached the attack. Sorry for my late comments regarding SP 800-38D. 

Best regards,

Yaobin Shen

[John Preuß Mattsson]

Hi Yaobin,

Thanks for sharing! I think your attack demonstrates very clearly why cryptographic specifications should never be paywalled.

Not only did this vulnerability exist in a paywalled ISO specification, but it remained undiscovered for nearly two decades. That is a powerful argument for making all cryptographic standards openly accessible so they can receive the broad public scrutiny that secure cryptography depends on.

Ericsson has removed all paywalled cryptographic specifications from our internal guidance, and we oppose normatively referencing paywalled cryptographic specifications in all SDOs.

Cheers,

John Preuß Mattsson