Hi all,
As described in our presentation at the 5th NIST
PQC workshop:
(Slides at
https://csrc.nist.gov/csrc/media/Presentations/2024/fips-204/images-media/perlner-fips-204-pqc2024.pdf)
we currently plan to make several changes when we publish the final version of FIPS 204 later this year in response to the helpful feedback we’ve received from the community.
We received 78 pages of comments from 37 different commenters
during the 90 day official comment period (Comments available at
https://csrc.nist.gov/csrc/media/Presentations/2024/fips-204/images-media/perlner-fips-204-pqc2024.pdf .)
We also received a number of comments before, during, and after on this forum. Thanks to everyone who commented!
In response to the comments we’ve received we plan to make the
following changes:
Changes we expect to affect the behavior of top level functions
(keygen, sign, verify)
-
In response to Vadim Lyubashevsky’s public comment, we plan to modify the ExpandMask algorithm so that it takes
output bits from the beginning of the SHAKE output rather than at an offset.
-
Also in response to Vadim Lyubashevsky’s public comment, we plan to modify the SampleInBall algorithm so that
it takes as input all of \tilde{c} rather than just the first 256 bits.
-
We plan to include fixed pseudocode for the HintBitUnpack algorithm. As pointed out to us in this forum thread
initiated by Mike Hamburg: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/TQo-qFbBO1A/m/YcYKjMblAAAJ ,
the pseudocode was missing an important check for correct formatting, and as a result the signature scheme described by draft FIPS 204 was not strongly unforgeable.
-
In coordination with the FIPS 205 team, we plane to introduce domain separation to both standards, to distinguish
between ML-DSA and a variant Hash-ML-DSA which includes an additional prehash step, and to allow the incorporation of a domain separated context string. More details are given in a separate forum post on the subject.
Selected changes for clarity, consistency, validation etc. that
we don’t expect to significantly affect the behavior of top level functions:
-
We expect the final FIPS 204 to have corrected the incorrect signature and private key lengths given in several places in draft FIPS 204. As pointed out by several commenters, these did not match the pseudocode.
-
As with FIPS 204, we plan to rewrite some of the uses of the XOF functions SHAKE128 and SHAKE256 to allow output bits to be generated incrementally. More details are given in a separate forum post on the subject
-
We plan to work with byte strings instead of bit strings wherever possible (exception: we will allow the input message to be a bit string.)
-
In response to Beat Heeb’s public comment, we plan to remove an unnecessary check from the pseudocode the verification algorithm.
-
We plan to explicitly allow implementers to limit the number of iterations in while loops. We intend to give a minimum allowable iteration limit, such that deviation from the behavior of the while loop is cryptographically rare for a correct implementation.
(A similar change is planned for FIPS 203.)
-
For testability, we will reorganize the pseudocode for the signing and key generation algorithms so that they call an internal derandomized version of signing and keygen, such that random values are passed in as explicit inputs. This internal function can then
be tested for correctness in a black box way. Similar changes are planned for FIPS 203 and FIPS 205. More details are given in a separate forum post on the subject.
-
We have introduced the use of “shall not” regarding use floating-point arithmetic.
Please let us know if you have any feedback or questions about
these proposed changes,
Thanks,
Ray Perlner
NIST PQC