[Federal Register Volume 89, Number 157 (Wednesday, August 14, 2024)]
[Notices]
[Pages 66052-66057]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-17956]
-----------------------------------------------------------------------
DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No. 240719-0201]
RIN 0693-XC131
Announcing Issuance of Federal Information Processing Standards
(FIPS) FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism
Standard, FIPS 204, Module-Lattice-Based Digital Signature Standard,
and FIPS 205, Stateless Hash-Based Digital Signature Standard
AGENCY: National Institute of Standards and Technology (NIST),
Commerce.
ACTION: Notice.
-----------------------------------------------------------------------
SUMMARY: This notice announces the Secretary of Commerce's approval of
three Federal Information Processing Standards (FIPS): FIPS 203,
Module-Lattice-Based Key-Encapsulation Mechanism Standard; FIPS 204,
Module-Lattice-Based Digital Signature Standard; and FIPS 205,
Stateless Hash-Based Digital Signature Standard. These standards
specify key establishment and digital signature schemes that are
designed to resist future attacks by quantum computers, which threaten
the security of current standards. The three algorithms specified in
these standards are each derived from different submissions in the NIST
post-quantum cryptography standardization project (see https://csrc.nist.gov/pqc-standardization).
DATES: FIPS 203, FIPS 204, and FIPS 205 are effective on August 14,
2024.
ADDRESSES: FIPS 203, FIPS 204, and FIPS 205 are available
electronically on the NIST Computer Security Resource Center website at
https://csrc.nist.gov. Comments that were received on the proposed
changes are published electronically at https://www.regulations.gov and
the NIST post-quantum cryptography standardization project website at
https://csrc.nist.gov/pqc-standardization.
FOR FURTHER INFORMATION CONTACT: Dr. Dustin Moody, National Institute
of Standards and Technology, 100 Bureau Drive, Mail Stop 8930,
Gaithersburg, MD 20899-8930, email: [email protected], phone: (301)
975-8136.
SUPPLEMENTARY INFORMATION: Over the past several years, there has been
steady progress toward building quantum computers. The security of many
commonly used public-key cryptosystems would be at risk if large-scale
quantum computers were ever realized. In particular, this would
[[Page 66053]]
include key-establishment schemes and digital signatures that are based
on integer factorization and discrete logarithms (both over finite
fields and elliptic curves). As a result, in 2017, the National
Institute of Standards and Technology (NIST) initiated a public process
to select quantum-resistant public-key cryptographic algorithms for
standardization. These quantum-resistant algorithms would augment the
public-key cryptographic algorithms already contained in FIPS 186-5,
Digital Signature Standard (DSS), as well as in NIST Special
Publication (SP) 800-56A Revision 3, Recommendation for Pair-Wise Key-
Establishment Schemes Using Discrete Logarithm Cryptography, and SP
800-56B Revision 2, Recommendation for Pair-Wise Key Establishment
Using Integer Factorization Cryptography.
NIST issued a public call for submissions to the Post-Quantum
Cryptography (PQC) Standardization Process in December 2016. Prior to
the November 2017 deadline, a total of 82 candidate algorithms were
submitted. Shortly thereafter, the 69 candidates that met both the
submission requirements and the minimum acceptability criteria were
accepted into the first round of the standardization process.
Submission packages for the first-round candidates were posted online
for public review and comment.
After a year-long review of the candidates, NIST selected 26
algorithms to move on to the second round of evaluation in January
2019. These algorithms were viewed as the most promising candidates for
eventual standardization and were selected based on both internal
analysis and public feedback. During the second round of evaluation,
there was continued evaluation of the analyses by NIST and the broader
cryptographic community. After consideration of these analyses and
other public input received throughout the evaluation process, NIST
selected seven finalists and eight alternates to move on to the third
round of evaluation in July 2020.
The third round of evaluation began in July 2020 and continued for
approximately 18 months. During the third round of evaluation, there
was a more thorough analysis of the theoretical and empirical evidence
used to justify the security of the 15 candidates (i.e., seven
finalists and eight alternates). There was also careful benchmarking of
their performance using optimized implementations on a variety of
software and hardware platforms. Similar to conferences held during the
first two rounds of evaluation, NIST also held the (virtual) Third NIST
PQC Standardization Conference in June 2021. NIST summarized its
decisions in a report at the end of each round, publishing NISTIR 8240
for the first round, NISTIR 8309 for the second round, and NISTIR 8413
for the third round. These reports are available at https://csrc.nist.gov/publications/ir.
After three rounds of evaluation and analysis, NIST selected four
algorithms it will standardize as a result of the PQC Standardization
Process. The public-key encapsulation mechanism selected was CRYSTALS-
KYBER, along with three digital signature schemes: CRYSTALS-Dilithium,
FALCON, and SPHINCS+. It is intended that these algorithms will be
capable of protecting sensitive U.S. Government information well into
the foreseeable future, including after the advent of quantum
computers.
FIPS 203 specifies a cryptographic scheme called Module-Lattice-
Based Key-Encapsulation Mechanism, or ML-KEM, which is derived from the
CRYSTALS-KYBER submission. A Key Encapsulation Mechanism (KEM) is a
particular type of key establishment scheme which can be used to
establish a shared secret key between two parties communicating over a
public channel. Current NIST-approved key establishment schemes are
specified in SP 800-56A, Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm-Based Cryptography, and in SP 800-56B,
Recommendation for Pair-Wise Key Establishment Schemes Using Integer
Factorization Cryptography.
FIPS 204 and 205 each specify digital signature schemes, which are
used to detect unauthorized modifications to data and to authenticate
the identity of the signatory. FIPS 204 specifies the Module-Lattice-
Based Digital Signature Algorithm (ML-DSA), which is derived from the
CRYSTALS-Dilithium submission. FIPS 205 specifies the Stateless Hash-
Based Digital Signature Algorithm (SLH-DSA), which is derived from the
SPHINCS+ submission. Current NIST-approved digital signature schemes
are specified in FIPS 186-5, Digital Signature Standard and SP 800-208,
Recommendation for Stateful Hash-based Signature Schemes. In the
future, NIST intends to develop a FIPS specifying a digital signature
algorithm derived from FALCON as an additional alternative to these
standards.
NIST published a notice in the Federal Register (88 FR 57938) on
August 24, 2023, requesting public comments on the drafts FIPS 203,
FIPS 204, and FIPS 205. For FIPS 203, NIST received 43 sets of
comments: three from U.S. federal agencies, one from a foreign
government agency, five from private-sector organizations, and 34 from
private academics and technologists. For FIPS 204, NIST received 37
sets of comments: two from U.S. federal agencies, one from a foreign
government agency, five from private-sector organizations, and 29 from
private academics and technologists. For FIPS 205, NIST received 23
sets of comments: two from U.S. federal agencies, two from a foreign
government agency, four from private-sector organizations, and 15 from
private academics and technologists. NIST addresses points made by
multiple commenters as singular comments in the sections following.
The following is a summary and analysis of the comments received
during the public comment period and NIST's responses to them,
including the interests, concerns, recommendations, and issues
considered in the development of FIPS 203, FIPS 204, and FIPS 205:
General Comments
Comment 1: Several commenters expressed interest in both general
and negative test vectors, with one explicit request for tests dealing
with input validation.
Response: While test vectors will not be included in the three PQC
FIPS, test vectors will be available on NIST's website.
Comment 2: Commenters noted that the usage of SHAKE in the draft
FIPS does not match the interfaces available in FIPS 202, SHA-3
Standard: Permutation-Based Hash and Extendable-Output Functions,
specifically interfaces where a variable amount of output is requested.
Response: NIST agrees with the comment noting the inconsistency
with FIPS 202. NIST is revising Special Publication 800-185, SHA-3
Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash, to
include a new application programming interface (API) to describe how
to use SHAKE to generate pseudorandom bits in a streaming fashion. The
text in the FIPS has been revised to accommodate this usage in the
revised final version.
Comment 3: One comment requested guidance for transitioning to PQC
algorithms to be included in the FIPS.
Response: NIST will provide additional transition guidance on the
migration to PQC following the publication of the FIPS. This guidance
will be published in forthcoming NIST guidelines and incorporated into
future revisions of relevant NIST publications. All NIST guidelines are
available on the NIST Computer Security Resource
[[Page 66054]]
Center website at https://csrc.nist.gov/publications.
Comment 4: One comment requested guidance for handling side-
channels to be included.
Response: Detailed implementation guidance, including side-channel
attack countermeasures, are outside the scope of the algorithm
specifications described in FIPS 203, FIPS 204, and FIPS 205.
Comment 5: Several commenters suggested moving the description of
the security categories in the Appendix to a different document or
revising the descriptions. Another commenter expressed concerns about
using the Advanced Encryption Standard (AES) as the security benchmark.
Response: The description of the security categories was removed
from the document and will be included in a future revision to Special
Publication 800-57 Part 1, Recommendation for Key Management. NIST
notes that the text used in the description of the security categories
mentioned a ``block cipher with 128-bit key (e.g., AES-128).'' Thus, a
generic block cipher (and not specifically AES) is what was described.
Comments on FIPS 203
Comment 6: To improve the efficiency of side-channel-resistant
implementations, two commenters suggested modifying the structure of
the shared secret key used in the case of failed checks during the ML-
KEM Decaps function. One comment suggested hashing the ciphertext
before use to shorten it, and another suggested inputting the
ciphertext before the secret value.
Response: While the suggestions may provide improvements in some
cases, this version of Decaps has not been sufficiently evaluated by
the community. Therefore, the current generation step was not modified.
Comment 7: Some commenters expressed concern about the input
validation checks required for ML-KEM Encaps and Decaps. One commenter
specifically requested removing the length check to support storing the
key as a seed. Two commenters requested removing the modulus check on
the value of public key. One commenter specifically mentioned the
difficulty that some programming languages support returning
exceptions.
Response: The input validation checks were included to provide an
appropriate amount of assurance that the public key is of the correct
type and format. Failure to obtain sufficient assurance can lead to
security vulnerabilities. As a result, NIST made no changes based on
these comments. NIST also notes that input validation should occur
before Encaps and Decaps so there should be no need for returning
exceptions.
Comment 8: A few commenters noted that the core algorithms within
ML-KEM are difficult to test because they are non-deterministic.
Response: NIST reconfigured the ML-KEM functions to sample
randomness before calling a more testing-friendly interface. The
functions were split into a deterministic function that accepts
randomness as input (to enable testing) and an externally callable
function that generates the needed randomness.
Comment 9: Several commenters offered many suggestions to improve
the readability of the document and correct small errors.
Response: NIST incorporated revisions throughout the FIPS to
improve clarity and correctness. In particular, the code comments in
ML-KEM pseudo-code were updated, along with adding footnotes to
reference comments that were too lengthy to include. The mathematical
symbols have also been reordered.
Comment 10: A few commenters requested further guidance on specific
implementation details of ML-KEM (e.g., handling bytes vs. bits,
avoiding floating-point operations, and avoiding pass-by-reference).
Response: NIST added language elaborating on these topics.
Specifically, NIST added explicit wording disallowing the usage of
floating-point arithmetic, and added explicit input copying in cases
where uncertainty with pass-by-references might cause confusion. In
addition, the algorithms were revised to only use byte strings, with
the exception of SHAKE. This is purely for syntactical conformance with
FIPS 202, which specifies SHAKE. It is expected that most ML-KEM
implementations will not implement conversions between bits and bytes
when invoking hash functions or extendable output functions (XOFs).
Comment 11: A few commenters expressed security concerns over
standardizing the parameter set ML-KEM-512 and requested its removal.
Other commenters specifically disagreed with removing ML-KEM-512.
Response: NIST made no changes based on these comments. NIST is
confident in the security of all the ML-KEM parameter sets and believes
they will serve many different use cases and applications on a wide
variety of computing platforms.
Comment 12: A few commenters expressed interest in guidance for
constructing different ML-KEM parameter sets for different performance
and security values.
Response: FIPS 203 specifies approved parameter sets to facilitate
interoperability and validation of implementations.
Comment 13: Several commenters expressed interest in guidance on
the secure usage of ML-KEM or KEMs in general. Some noted they expect
such usage to be in a referenced SP 800-227 but noted that this
document is currently unavailable. One comment requested guidance on
applications of KEMs.
Response: NIST will provide guidance on the secure usage and
applications of KEMs in the forthcoming SP 800-227, Recommendations for
Key Encapsulation Mechanisms. A draft will be published for public
comment on the NIST Computer Security Resource Center website in the
second half of 2024.
Comment 14: A few commenters requested that the approved usage of
ML-KEM shared secret keys be extended to the key derivation methods
found in SP 800-56C, Recommendation for Key-Derivation Methods in Key-
Establishment Schemes.
Response: NIST updated FIPS 203 to allow the key derivation methods
in SP 800-56C to apply to keys generated as specified in FIPS 203 in
place of shared secrets. When combining the key derivation with another
key establishment or key exchange procedure, then the security of the
combined procedure needs to be assessed on a case-by-case basis. More
guidance will be provided in SP 800-227, Recommendations for Key-
Encapsulation Mechanisms, a draft of which will be published for public
comment on the NIST Computer Security Resource Center website in the
second half of 2024.
Comment 15: One commenter recommended that NIST require the use of
hybrid implementations, specifically using ML-KEM with another pre-
quantum, standardized algorithm for security reasons.
Response: NIST is confident in the security of the standardized
algorithms, which included a six-year public evaluation process and
public review of the specifications in the draft FIPS publications.
While NIST will not require that ML-KEM, or the other PQC algorithms,
be used in hybrid schemes that incorporate a second standardized
algorithm, it will ensure that its cryptographic standards support
security protocols and applications that choose to implement hybrid
approaches. Additional guidance relevant to hybrid approaches is being
developed within NIST guidelines on key derivation methods and key
[[Page 66055]]
encapsulation mechanisms, as described in the response to Comment 14.
Comment 16: Several commenters noted that the indexing used for
generating the A matrix in FIPS 203 swapped the indexing used in the
CRYSTALS-Kyber specification.
Response 17: NIST changed the matrix indexing to match the
CRYSTALS-Kyber specification.
Comment 18: Many commenters requested alternatives to and
replacements for the XOFs and hash functions used inside ML-KEM,
including Ascon and SHA-2. Several commenters requested no replacements
be made for these functions.
Response: NIST made no changes based on these comments. Introducing
alternative functions would create several new options which could
hinder interoperability and adoption.
Comment 19: Several commenters requested NIST reintroduce a step in
the ML-KEM Encaps function from the third-round specification of Kyber.
This step hashed the randomness received from the system before its use
in Encaps. They noted this step provided defense in depth and helped
ensure security in the case of imperfect random bit generator (RBG)
output. One commenter supported its removal.
Response: NIST did not reintroduce the hash of randomness into the
Encaps. Hashing the RBG output within ML-KEM is an ineffective
countermeasure against a faulty RBG. For example, other cryptographic
algorithms or applications on a device could leak information from a
faulty RBG regardless of countermeasures implemented within ML-KEM.
This issue is addressed in FIPS 203 by requiring ML-KEM to be used only
alongside an approved RBG as specified in SP 800-90A, Recommendation
for Random Number Generation using Deterministic Random Bit Generators.
Comment 20: Some commenters requested NIST restore a step in the
ML-KEM Encaps function from the previous version. This step updated the
shared secret key with a hash of the ciphertext. Some motivation
expressed include reverting a late-stage change and providing better
security properties when ML-KEM is used in future applications.
Response: The indistinguishability under adaptive chosen ciphertext
attack (IND-CCA2) security of ML-KEM does not require the ciphertext to
be hashed during ML-KEM Encaps. NIST notes that this change was
publicly proposed by the CRYSTALS-Kyber team in December 2022 and was
followed by extensive public discussion. Due to no known security
benefits for reverting to this step, NIST did not add back the hash of
the ciphertext.
Comment 21: Many commenters expressed interest in allowance and
guidance for storing a small seed string in place of the larger keys
for ML-KEM, using the seed string to regenerate keys on demand during
operation.
Response: NIST revised FIPS 203 to clarify that keys can be
regenerated from saved seed values.
Comment 22: A few commenters raised issues related to the
requirement for the Decaps function to implicitly reject on a protocol
failure.
Response: Implicit rejection within ML-KEM has been maintained for
consistency with the CRYSTALS-KYBER submission.
Comment 23: One commenter requested that the seed size be increased
to 40 bytes for ML-KEM key generation to avoid multi-target attacks.
Response: NIST maintained the seed length as provided in the draft
FIPS 203, noting that the seed of 32 bytes is sufficient to protect
against multitarget attacks at security categories 1 and 3. Hardening
category 5 would require further changes to ML-KEM beyond the extended
seed. In addition, single target security should be sufficient for any
plausible scenario (at category 5).
Comment 24: One comment noted outdated decapsulation failure rates
for ML-KEM.
Response: NIST revised the decapsulation failure rates provided in
FIPS 203 based on technical updates from the submitters of the
CRYSTALS-KYBER algorithm. The rates changed by at most one order of
magnitude for each parameter set.
Comment 25: One comment requested the addition of a table of
precomputed values for ``zetas'' in number theory transform (NTT)
computations, similar to ML-DSA.
Response: NIST added the relevant table of precomputed values as
requested.
Comments on FIPS 204
Comment 26: Many comments about minor edits, including errors,
inconsistencies, presentation, confusion, potential for confusion, and
requests for clarification.
Response: NIST made several minor editorial changes to improve
clarity where requested. In particular, ExpandMask and the call to
SampleInBall in Sign have been slightly revised. Specifically, the
input to SampleInBall in Sign is now the whole commitment hash value
instead of just the first 256 bits. As for ExpandMask, the call to
``IntegerToBits'' is replaced with ``IntegerToBytes'', and the variable
v is now always assigned bytes from the beginning of hash output. The
Verify algorithm has also been simplified following a suggestion to
remove the check for the Hamming weight of the hint vector.
Comment 27: One comment requested swapping the order of tr and M as
inputs to a hash function in the Sign algorithm in order to simplify
implementations of some digital signature APIs.
Response: After reviewing the digital signature APIs referenced by
the commenter, NIST determined that the potential to simplify API
implementations through the proposed change was not significant enough
to justify a deviation from the CRYSTALS-Dilithium specification as
evaluated in the third round and which would have required additional
changes to implementations of the draft standard.
Comment 28: A few commenters mentioned the mixed usage of bit
strings and byte strings and noted that this could cause confusion.
Response: The revised FIPS 204 uses byte strings as input and
output to/from most of the algorithms, with the limited exceptions that
follow. The input to and output from SHAKE are bit strings. This is
consistent with FIPS 202, which specifies SHAKE. Input to BitsToInteger
and output from IntegerToBits are also bit strings. It is expected that
most implementations will not implement conversions between bits and
bytes. Moreover, the revised FIPS 204 has defined the hash functions H
and G to be byte-oriented versions of SHAKE256 and SHAKE128
respectively, so that bit strings are only used in the pseudocode where
necessary to deal with an input message that is not a whole number of
bytes.
Comment 29: Several commenters requested clarification on the
``pre-hash'' version of ML-DSA (i.e., when the message that is signed
by ML-DSA may be the digest of the content that is to be protected by
the signature).
Response: NIST proposed a more fully specified pre-hash version on
the PQC mailing list, and also held a panel on this topic at the fifth
NIST PQC Standardization Conference. Using the feedback obtained, FIPS
204 contains a revised specification of pre-hashing. It also now
specifies domain separation to ensure that pre-hashed messages can be
distinguished from non-pre-hashed messages. FIPS 204 specifies that the
signature identifier should indicate whether or not the message was
pre-hashed.
Comment 30: One commenter requested the usage of SHAKE in ML-DSA be
changed to the hash function
[[Page 66056]]
SHA2. Another commenter suggested allowing ASCON as an alternative to
SHAKE.
Response: NIST made no changes based on these comments, as neither
using ASCON nor SHA2 was studied during the three rounds of evaluation
of the NIST standardization process.
Comment 31: A few commenters asked for clarification regarding
storing the seed used to regenerate the public and private keys, as an
alternative to storing the keys.
Response: FIPS 204 was revised to clarify that seeds may be stored
and used to regenerate public and private keys.
Comment 32: One commenter proposed changing the length of the seed
used for key generation to at least 40 bytes to protect against multi-
target attacks.
Response: NIST did not modify the seed length, as the current 32-
byte seed is sufficient to protect against multitarget attacks at
security categories 2 and 3. The seed was at 32-bytes to maintain
consistency with ML-KEM, where getting multi-target security at
category 5 would require further changes beyond a longer seed. At
category 5, single-target security should be sufficient for any
plausible use case.
Comment 33: Some commenters asked for a randomized version of ML-
DSA where the sampling of y is done using randomness directly from an
RBG.
Response: FIPS 204 was not revised to include a randomized version.
While a randomized version could enable more efficient side-channel
protections, it would be difficult to validate implementations for
conformance.
Comment 34: One commenter requested that a reduced round version of
SHAKE be allowed for use in FIPS 204.
Response: A reduced round version of SHAKE (e.g., TurboSHAKE) is
not currently specified in a FIPS. While such a change would provide a
performance improvement, this was not evaluated during the three rounds
of evaluation in the NIST PQC standardization process.
Comments on FIPS 205
Comment 35: A few commenters suggested reducing the number of
parameter sets that are specified in the standard.
Response: NIST made no changes based on these comments. While there
was some support for reducing the number of parameter sets, others
believed that all twelve parameter sets should remain. In addition,
among those who recommended reducing the number of parameter sets,
there was no consensus as to which parameter sets should be removed.
Comment 36: One commenter requested that additional parameter sets
be specified that have smaller signature sizes, but for which the
number of signatures that can safely be generated is less than 2\64\.
Response: NIST intends to propose such parameter sets in a separate
Special Publication.
Comment 37: Several commenters requested clarification on the
``pre-hash'' version of SLH-DSA (i.e., when the message that is signed
by SLH-DSA may be the digest of the content that is to be protected by
the signature).
Response: NIST proposed a more fully specified pre-hash version on
the PQC mailing list, and also held a panel on this topic at the fifth
NIST PQC Standardization Conference. Using the feedback provided, FIPS
205 contains a revised specification of pre-hashing. It also now
specifies domain separation to ensure that pre-hashed messages can be
distinguished from non-pre-hashed messages. FIPS 205 specifies that the
signature identifier should indicate whether or not the message was
pre-hashed.
Comment 38: One commenter suggested replacing SHA-256 and SHA-512
with SHA-256SLH-DSA and SHA-512SLH-DSA. The new
functions would be the same as the current ones, with the exception
that the padded message would be reordered so that all constant
information (including padding) would be processed before the variable
information. Another commenter suggested replacing SHAKE256 with
TurboSHAKE256, which reduces the number of rounds in the permutation
function from 24 to 12.
Response: No changes were made based on these comments. While the
proposed changes might provide some performance improvement, the
improvements were not considered significant enough to justify
considering the use of cryptographic primitives that are not currently
specified in NIST standards.
Comment 39: Several commenters requested clarifications to the text
describing addresses.
Response: FIPS 205 was revised to include tables showing the member
functions for manipulating addresses, supplementing the text and the
figures illustrating each of the address types. Information about
compressed addresses was also revised.
Summary of Changes to FIPS 203, FIPS 204, and FIPS 205
The following is a summary of the changes made to FIPS 203, FIPS
204, and FIPS 205.
In FIPS 203, FIPS 204, and FIPS 205, the main functions now each
call an internal derandomized function in order to facilitate
validation of implementations of these algorithms. In FIPS 203, this
applies to KeyGen, Encaps and Decaps. In FIPS 204 and FIPS 205, this
applies to KeyGen, Sign, and Verify. In addition, to offer misuse
resistance against the possibility that keys for different parameter
sets might be expanded from the same seed, domain separation was added
to the key generation routine.
In FIPS 203 and FIPS 204, a new API is now used to invoke functions
from the SHAKE family. This API allows for appropriately streaming
pseudorandom bytes from a SHAKE XOF in situations where no a-priori
bound is known on the total number of needed bytes. This API will also
be described and used in the next revision of NIST SP 800-185, SHA-3
Derived Functions.
Language was added in FIPS 203 and FIPS 204 to clarify that some
intermediate values can be stored in order to speed up certain
computations. Some of these stored values can be computed from the
public key, and thus do not require any special safeguards, while
others require the same protections as the private key.
In FIPS 203 and FIPS 204, it is now permitted to terminate certain
rejection sampling loops once a required minimum number of attempts is
made.
The differences between CRYSTAL-KYBER and ML-KEM are now described
in Appendix C of FIPS 203.
Based on comments submitted on draft FIPS 203, domain separation
was added to the key generation routine to prevent the misuse of keys
generated to target one security level from being used for a different
security level when saving a key as a seed.
The draft of FIPS 203 had inadvertently changed the order in which
the algorithms generated the entries of the matrix A in the public key
of ML-KEM. This was changed back in the final specification of ML-KEM
in FIPS 203 to match CRYSTALS-KYBER as specified in the third round of
the PQC Standardization Process.
The differences between CRYSTAL-Dilithium and ML-DSA are now
described in Appendix D of FIPS 204. Based on comments that were
submitted on the draft version, in the final version of ML-DSA, as
specified in FIPS 204, the malformed input check, which had
[[Page 66057]]
been omitted from draft FIPS 204, was restored to the hint unpacking
algorithm. Additionally, rather than using just the first 256 bits of
the commitment hash, ~c, as the input to SampleInBall, the full
commitment hash is used. Also, ExpandMask is modified to take output
bits from the beginning rather than at an offset.
Based on comments that were submitted on draft FIPS 204, more
details were provided for the pre-hash version, HashML-DSA. These
modifications include domain separation for the cases in which the
message is signed directly and cases in which a digest of the message
is signed. The changes were made by modifying the inputs to the
internal signing and verification functions.
The differences between SPHINCS+ specification and SLH-DSA are
described in Appendix A of FIPS 205. Based on comments that were
submitted on draft FIPS 205, the SLH-DSA signature generation and
verification functions were modified to include domain separation cases
in which the message is signed directly and cases in which a digest of
the message is signed. The changes were made by modifying the inputs to
the signing and verification functions.
Authority: 40 U.S.C. 11331(f), 15 U.S.C. 278g-3.
Alicia Chambers,
NIST Executive Secretariat.
[FR Doc. 2024-17956 Filed 8-13-24; 8:45 am]
BILLING CODE 3510-13-P