FIPS 204 errata

[Moody, Dustin (Fed)]

All,

We were alerted of a minor mistake in FIPS 204 this week.  Thanks to Julian Brough and Aleksejs Zajakins for pointing it out to us.  It involves having an extra 'w' in the sections where we talk about NTT.  It only involved text describing the NTT - the algorithms given in FIPS 204 did not have the mistake.  See below for details.   We only plan to potentially open FIPS 204 for any needed revisions in five years, so this would be corrected in a future update.  For now, the page for FIPS 204

https://csrc.nist.gov/pubs/fips/204/final

includes a note letting people know about this issue in an errata.  Any other such mistakes discovered will be noted there as well.  

Dustin Moody

NIST PQC

>>>>>>>>>>>>>

Location: FIPS 204, Sections 2.5 and 7.5. (the same text is in both)

 

Issue: 

As written in the explanation of NTT, the polynomial w gets evaluated twice when it should be only once.  Concretely, In equations (2.1) and (7.1) the NTT is explicitly written as NTT(w)_j=w(\zeta_j) and the following line says "where \zeta_j=w(\zeta^{2BitRev_8(i)+1} ) mod q".
This would mean that each coordinate of the NTT requires evaluating the polynomial w twice, first at \zeta^{2BitRev_8(i)+1} and then again at \zeta_j.  In other words computing w ( w (\zeta^{2BitRev_8(i)+1} )).

 

Potential correction:  

The polynomial w should only be evaluated once.  One should replace “where \zeta_j=w(\zeta^{2BitRev_8(i)+1} ) mod q.” with “where \zeta_j=\zeta^{2BitRev_8(i)+1}  mod q.”  This change should occur both in section 2.5 and 7.5, immediately following equations (2.1) and (7.1).

[John Mattsson]

Hi,

 

While commenting on the Composite ML-DSA draft [1], I looked at what FIPS 204 says about seed, input, output, external functions, and internal functions. I think it would be good if NIST added a row in the FIPS 204 Errata (potential updates) [2] to clarify things.

 

---

 

FIPS 204 specifies the external function

 

(pk, sk) = ML-DSA.KeyGen()

 

and the internal function

 

(pk, sk) = ML-DSA.KeyGen_internal(𝜉)

 

and states:

 

"The seed 𝜉 generated in step 1 of ML-DSA.KeyGen can be stored for the purpose of later expansion using ML-DSA.KeyGen_internal."

 

"Other than for testing purposes, the interfaces for key generation and signature generation specified

in this section should not be made available to applications"

 

"Therefore, implementations of ML-DSA shall ensure that any potentially sensitive intermediate data is

destroyed as soon as it is no longer needed."

 

---

 

At least in the IETF, storing the seed 𝜉 is clearly the preferred way to implement ML-DSA. However it is unclear how NIST thinks this should be implemented

 

- Should ML-DSA.KeyGen_internal(𝜉) be made external, or should there be a new separate external function (pk, sk) = ML-DSA.KeyGen2(𝜉). I don’t see any problem with making ML-DSA.KeyGen_internal(𝜉) external.

 

- The current text: can store seed, shall destroy, internal should not be made available, could be read as FIPS 204 discourage use of seed, which at least is not aligned with the IETF.

 

Cheers,

John

[1] https://mailarchive.ietf.org/arch/msg/spasm/8-S68UybQoSfi9T4Xp1SboZWp7Y/

 

[2] https://csrc.nist.gov/files/pubs/fips/204/final/docs/fips-204-potential-updates.xlsx

 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB86690BB0986A6D758ED24A00E5682%40SA1PR09MB8669.namprd09.prod.outlook.com.

[Deirdre Connolly]

Agree

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB9678B84C0AA3EBB713274608891CA%40GVXPR07MB9678.eurprd07.prod.outlook.com.

[Stephan Mueller]

Am Mittwoch, 24. September 2025, 15:41:34 Mitteleuropäische Sommerzeit schrieb
Deirdre Connolly:

Hi Deirdre,

> Agree
>
> On Wed, Sep 24, 2025, 4:17 AM 'John Mattsson' via pqc-forum <
>
> pqc-...@list.nist.gov> wrote:
> > Hi,
> >
> >
> >
> > While commenting on the Composite ML-DSA draft [1], I looked at what FIPS
> > 204 says about seed, input, output, external functions, and internal
> > functions. I think it would be good if NIST added a row in the FIPS 204
> > Errata (potential updates) [2] to clarify things.
> >
> >
> >
> > ---
> >
> >
> >
> > FIPS 204 specifies the external function
> >
> >
> >
> > (pk, sk) = ML-DSA.KeyGen()
> >
> >
> >
> > and the internal function
> >
> >
> >
> > (pk, sk) = ML-DSA.KeyGen_internal(𝜉)
> >
> >
> >
> > and states:
> >
> >
> >

> > "The seed 𝜉 generated in step 1 of ML-DSA.KeyGen *can* be stored for the

> > purpose of later expansion using ML-DSA.KeyGen_internal."
> >
> >
> >
> > "Other than for testing purposes, the interfaces for key generation and
> > signature generation specified
> >

> > in this section *should not* be made available to applications"
> >
> >
> >
> > "Therefore, implementations of ML-DSA *shall* ensure that any potentially

> > sensitive intermediate data is
> >
> > destroyed as soon as it is no longer needed."

A similar concern, however, is applicable to ML-KEM / FIPS 203 as well:

Section 7.1 reads

"""
The seed (𝑑, 𝑧) generated in steps 1 and 2 of ML-KEM.KeyGen can be stored for
later expan-
sion using ML-KEM.KeyGen_internal (see Section 3.3).
"""

vs

"""
The interfaces for these [the internal] functions should not
be made available to applications other than for testing purposes.
"""

Ciao
Stephan