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, 66052-66057 [2024-17956]
Download as PDF
66052
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
(ii) evidence submitted in support of
allegations; (iii) publicly available
information to value factors under 19
CFR 351.408(c) or to measure the
adequacy of remuneration under 19 CFR
351.511(a)(2); (iv) evidence placed on
the record by Commerce; and (v)
evidence other than factual information
described in (i)–(iv). These regulations
require any party, when submitting
factual information, to specify under
which subsection of 19 CFR
351.102(b)(21) the information is being
submitted and, if the information is
submitted to rebut, clarify, or correct
factual information already on the
record, to provide an explanation
identifying the information already on
the record that the factual information
seeks to rebut, clarify, or correct. The
regulations, at 19 CFR 351.301, also
provide specific time limits for such
factual submissions based on the type of
factual information being submitted.
Please review the Final Rule,12 available
at https://www.govinfo.gov/content/pkg/
FR-2013-07-17/pdf/2013-17045.pdf,
prior to submitting factual information
in this segment. Note that Commerce
has amended certain of its requirements
pertaining to the service of documents
in 19 CFR 351.303(f).13
Any party submitting factual
information in an AD or CVD
proceeding must certify to the accuracy
and completeness of that information
using the formats provided at the end of
the Final Rule.14 Commerce intends to
reject factual submissions in any
proceeding segments if the submitting
party does not comply with applicable
certification requirements.
ddrumheller on DSK120RN23PROD with NOTICES1
Extension of Time Limits Regulation
Parties may request an extension of
time limits before a time limit
established under Part 351 expires, or as
otherwise specified by Commerce.15 In
general, an extension request will be
considered untimely if it is filed after
the time limit established under Part
351 expires. For submissions which are
due from multiple parties
simultaneously, an extension request
will be considered untimely if it is filed
after 10:00 a.m. on the due date.
Examples include, but are not limited
to: (1) case and rebuttal briefs, filed
pursuant to 19 CFR 351.309; (2) factual
information to value factors under 19
CFR 351.408(c), or to measure the
adequacy of remuneration under 19 CFR
351.511(a)(2), filed pursuant to 19 CFR
351.301(c)(3) and rebuttal, clarification
and correction filed pursuant to 19 CFR
351.301(c)(3)(iv); (3) comments
concerning the selection of a surrogate
country and surrogate values and
rebuttal; (4) comments concerning CBP
data; and (5) Q&V questionnaires. Under
certain circumstances, Commerce may
elect to specify a different time limit by
which extension requests will be
considered untimely for submissions
which are due from multiple parties
simultaneously. In such a case,
Commerce will inform parties in the
letter or memorandum setting forth the
deadline (including a specified time) by
which extension requests must be filed
to be considered timely. This policy also
requires that an extension request must
be made in a separate, standalone
submission, and clarifies the
circumstances under which Commerce
will grant untimely-filed requests for the
extension of time limits. Please review
the Final Rule, available at https://
www.gpo.gov/fdsys/pkg/FR-2013-09-20/
html/2013-22853.htm, prior to
submitting factual information in these
segments.
These initiations and this notice are
in accordance with section 751(a) of the
Act (19 U.S.C. 1675(a)) and 19 CFR
351.221(c)(1)(i).
Dated: August 8, 2024.
Scot Fullerton,
Acting Deputy Assistant Secretary for
Antidumping and Countervailing Duty
Operations.
[FR Doc. 2024–18103 Filed 8–13–24; 8:45 am]
BILLING CODE 3510–DS–P
12 See Certification of Factual Information To
Import Administration During Antidumping and
Countervailing Duty Proceedings, 78 FR 42678 (July
17, 2013) (Final Rule); see also the frequently asked
questions regarding the Final Rule, available at
https://enforcement.trade.gov/tlei/notices/factual_
info_final_rule_FAQ_07172013.pdf.
13 See Administrative Protective Order, Service,
and Other Procedures in Antidumping and
Countervailing Duty Proceedings; Final Rule, 88 FR
67069 (September 29, 2023).
14 See section 782(b) of the Act; see also Final
Rule; and the frequently asked questions regarding
the Final Rule, available at https://
enforcement.trade.gov/tlei/notices/factual_info_
final_rule_FAQ_07172013.pdf.
15 See 19 CFR 351.302.
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
PO 00000
Frm 00023
Fmt 4703
Sfmt 4703
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-LatticeBased Digital Signature Standard, and
FIPS 205, Stateless Hash-Based Digital
Signature Standard
National Institute of Standards
and Technology (NIST), Commerce.
ACTION: Notice.
AGENCY:
This notice announces the
Secretary of Commerce’s approval of
three Federal Information Processing
Standards (FIPS): FIPS 203, ModuleLattice-Based Key-Encapsulation
Mechanism Standard; FIPS 204,
Module-Lattice-Based Digital Signature
Standard; and FIPS 205, Stateless HashBased 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/pqcstandardization).
SUMMARY:
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 postquantum 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: Dustin.Moody@
nist.gov, 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 largescale quantum computers were ever
realized. In particular, this would
DATES:
E:\FR\FM\14AUN1.SGM
14AUN1
ddrumheller on DSK120RN23PROD with NOTICES1
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
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 quantumresistant 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 PairWise 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)
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
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 PairWise 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
PO 00000
Frm 00024
Fmt 4703
Sfmt 4703
66053
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 privatesector 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
E:\FR\FM\14AUN1.SGM
14AUN1
66054
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
ddrumheller on DSK120RN23PROD with NOTICES1
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
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
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.
PO 00000
Frm 00025
Fmt 4703
Sfmt 4703
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 KeyEstablishment 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 KeyEncapsulation 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 prequantum, 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
E:\FR\FM\14AUN1.SGM
14AUN1
ddrumheller on DSK120RN23PROD with NOTICES1
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
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
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
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
PO 00000
Frm 00026
Fmt 4703
Sfmt 4703
66055
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 ‘‘prehash’’ 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 prehashed.
Comment 30: One commenter
requested the usage of SHAKE in ML–
DSA be changed to the hash function
E:\FR\FM\14AUN1.SGM
14AUN1
66056
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
ddrumheller on DSK120RN23PROD with NOTICES1
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
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
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 264.
Response: NIST intends to propose
such parameter sets in a separate
Special Publication.
Comment 37: Several commenters
requested clarification on the ‘‘prehash’’ 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 prehashed.
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.
PO 00000
Frm 00027
Fmt 4703
Sfmt 4703
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 CRYSTALDilithium 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
E:\FR\FM\14AUN1.SGM
14AUN1
Federal Register / Vol. 89, No. 157 / Wednesday, August 14, 2024 / Notices
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
DEPARTMENT OF COMMERCE
National Oceanic and Atmospheric
Administration
[RTID 0648–XE180]
Takes of Marine Mammals Incidental to
Specified Activities; Taking Marine
Mammals Incidental To Ferndale
Refinery Dock Maintenance and Pile
Replacement Activities in Ferndale,
Washington
National Marine Fisheries
Service (NMFS), National Oceanic and
Atmospheric Administration (NOAA),
Commerce.
ACTION: Notice; issuance of an incidental
harassment authorization.
ddrumheller on DSK120RN23PROD with NOTICES1
AGENCY:
In accordance with the
regulations implementing the Marine
Mammal Protection Act (MMPA) as
amended, notification is hereby given
that NMFS has issued an incidental
harassment authorization (IHA) to
Phillips 66 Co. to incidentally harass
SUMMARY:
VerDate Sep<11>2014
18:22 Aug 13, 2024
Jkt 262001
marine mammals during construction
activities associated with a dock
replacement project in Ferndale,
Washington.
DATES: This authorization is effective
from August 1 through July 31, 2025.
ADDRESSES: Electronic copies of the
application and supporting documents,
as well as a list of the references cited
in this document, may be obtained
online at: https://
www.fisheries.noaa.gov/action/
incidental-take-authorization-phillips66-cos-ferndale-refinery-dockmaintenance-and-pile. In case of
problems accessing these documents,
please call the contact listed below.
FOR FURTHER INFORMATION CONTACT:
Jennifer Gatzke, Office of Protected
Resources, NMFS, (301) 427–8401.
SUPPLEMENTARY INFORMATION:
Background
The MMPA prohibits the ‘‘take’’ of
marine mammals, with certain
exceptions. Sections 101(a)(5)(A) and
(D) of the MMPA (16 U.S.C. 1361 et
seq.) direct the Secretary of Commerce
(as delegated to NMFS) to allow, upon
request, the incidental, but not
intentional, taking of small numbers of
marine mammals by U.S. citizens who
engage in a specified activity (other than
commercial fishing) within a specified
geographical region if certain findings
are made and either regulations are
proposed or, if the taking is limited to
harassment, a notice of a proposed IHA
is provided to the public for review.
Authorization for incidental takings
shall be granted if NMFS finds that the
taking will have a negligible impact on
the species or stock(s) and will not have
an unmitigable adverse impact on the
availability of the species or stock(s) for
taking for subsistence uses (where
relevant). Further, NMFS must prescribe
the permissible methods of taking and
other ‘‘means of effecting the least
practicable adverse impact’’ on the
affected species or stocks and their
habitat, paying particular attention to
rookeries, mating grounds, and areas of
similar significance, and on the
availability of the species or stocks for
taking for certain subsistence uses
(referred to in shorthand as
‘‘mitigation’’); and requirements
pertaining to the monitoring and
reporting of the takings. The definitions
of all applicable MMPA statutory terms
cited above are included in the relevant
sections below.
Summary of Request
On February 29, 2024 we received a
request from Phillips 66 for an IHA to
take marine mammals incidental to
PO 00000
Frm 00028
Fmt 4703
Sfmt 4703
66057
Ferndale Refinery Dock Maintenance
and Pile Replacement Activities in
Ferndale, Washington. Following
NMFS’ review of the application,
Phillips 66 submitted revised versions
on May 16 and May 20, 2024. The
application was deemed adequate and
complete on May 21, 2024. Phillips 66
has requested authorization of take by
Level B harassment for harbor seal,
California sea lion, Steller sea lion and
harbor porpoise. Neither Phillips 66 nor
NMFS expect serious injury or mortality
to result from this activity and,
therefore, an IHA is appropriate. There
are no changes from the proposed
authorization to the final authorization.
Description of the Specified Activity
Phillips 66 is planning to modernize
the existing timber loading dock (on the
southeastern shoreline of the Strait of
Georgia in Ferndale, Washington) and
replace it with a stronger structure that
meets current industry best practices.
The activity includes installation of
steel piles by vibratory driving, and pile
removal using an underwater chainsaw
or cutting torch.
In-water pile installation construction
will occur for 35 days, which will occur
intermittently through approximately
October 31, 2024. Take of marine
mammals is anticipated to occur due to
vibratory pile installation. Removal of
all piles is expected to take up to 66
days for underwater pile cutting with a
chainsaw. Take of marine mammals is
not anticipated to occur due to pile
removal.
This IHA is valid for a period of 1
year from the date of issuance. Due to
in-water work timing restrictions to
protect Endangered Species Act (ESA)listed salmonids, all planned in-water
construction in this area is limited to a
work window beginning August 1 and
ending February 1. However, since the
Strait of Georgia is a very large water
body with a long fetch, calm in-water
work conditions are typically only
available from August to the end of
October. Pile removal processes are less
dependent on good weather, and this
portion of the project may occur from
approximately August 1 to February 1.
Therefore, Phillips 66 expects that inwater pile installation construction
work will occur through October 31,
2024. Pile driving is anticipated to take
up to 35 days to complete. Work may
occur on nonconsecutive days due to
weather and other project needs. Pile
driving will be completed intermittently
throughout daylight hours.
A detailed description of the planned
dock maintenance and pile replacement
project is provided in the Federal
Register notice for the proposed IHA (89
E:\FR\FM\14AUN1.SGM
14AUN1
Agencies
[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