rfc9882v3.txt   rfc9882.txt 
skipping to change at line 79 skipping to change at line 79
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
post-quantum digital signature algorithm standardised by the US post-quantum digital signature algorithm standardised by the US
National Institute of Standards and Technology (NIST) as part of National Institute of Standards and Technology (NIST) as part of
their post-quantum cryptography standardisation process. It offers their post-quantum cryptography standardisation process. It offers
smaller signatures and significantly faster runtimes than SLH-DSA smaller signatures and significantly faster runtimes than SLH-DSA
[FIPS205], an alternative post-quantum signature algorithm also [FIPS205], an alternative post-quantum signature algorithm also
standardised by NIST. This document specifies the use of the ML-DSA standardised by NIST. This document specifies the use of ML-DSA in
in the CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML- the CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-
DSA-87. See Appendix B of [RFC9881] for more information on the 87. See Appendix B of [RFC9881] for more information on the security
security levels and key sizes of ML-DSA. levels and key sizes of ML-DSA.
Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and
Dilithium are not compatible. Dilithium are not compatible.
For each of the ML-DSA parameter sets, an algorithm identifier OID For each of the ML-DSA parameter sets, an algorithm identifier OID
has been specified. has been specified.
[FIPS204] also specifies a pre-hashed variant of ML-DSA, called [FIPS204] also specifies a pre-hashed variant of ML-DSA, called
HashML-DSA. Use of HashML-DSA in the CMS is not specified in this HashML-DSA. Use of HashML-DSA in the CMS is not specified in this
document. See Section 3.1 for more details. document. See Section 3.1 for more details.
skipping to change at line 162 skipping to change at line 162
3.1. Pure Mode Versus Pre-Hash Mode 3.1. Pure Mode Versus Pre-Hash Mode
[RFC5652] specifies that digital signatures for CMS are produced [RFC5652] specifies that digital signatures for CMS are produced
using a digest of the message to be signed and the signer's private using a digest of the message to be signed and the signer's private
key. At the time RFC 5652 was published, all signature algorithms key. At the time RFC 5652 was published, all signature algorithms
supported in the CMS required a message digest to be calculated supported in the CMS required a message digest to be calculated
externally to that algorithm, which would then be supplied to the externally to that algorithm, which would then be supplied to the
algorithm implementation when calculating and verifying signatures. algorithm implementation when calculating and verifying signatures.
Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also
been standardised, and these algorithms support both a "pure" and been standardised, and these algorithms support both a "pure" and a
"pre-hash" mode. In the pre-hash mode, a message digest (the "pre- "pre-hash" mode. In the pre-hash mode, a message digest (the "pre-
hash") is calculated separately and supplied to the signature hash") is calculated separately and supplied to the signature
algorithm as described above. In the pure mode, the message to be algorithm as described above. In the pure mode, the message to be
signed or verified is instead supplied directly to the signature signed or verified is instead supplied directly to the signature
algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with
CMS, only the pure mode of those algorithms is specified. This is CMS, only the pure mode of those algorithms is specified. This is
because in most situations, CMS signatures are computed over a set of because in most situations, CMS signatures are computed over a set of
signed attributes that contain a hash of the content, rather than signed attributes that contain a hash of the content, rather than
being computed over the message content itself. Since signed being computed over the message content itself. Since signed
attributes are typically small, use of pre-hash modes in the CMS attributes are typically small, use of pre-hash modes in the CMS
skipping to change at line 319 skipping to change at line 319
verification of a signature. verification of a signature.
4. Security Considerations 4. Security Considerations
The security considerations in [RFC5652] and [RFC9881] apply to this The security considerations in [RFC5652] and [RFC9881] apply to this
specification. specification.
Security of the ML-DSA private key is critical. Compromise of the Security of the ML-DSA private key is critical. Compromise of the
private key will enable an adversary to forge arbitrary signatures. private key will enable an adversary to forge arbitrary signatures.
ML-DSA depends on high quality random numbers that are suitable for ML-DSA depends on high-quality random numbers that are suitable for
use in cryptography. The use of inadequate pseudo-random number use in cryptography. The use of inadequate pseudo-random number
generators (PRNGs) to generate such values can significantly generators (PRNGs) to generate such values can significantly
undermine the security properties offered by a cryptographic undermine the security properties offered by a cryptographic
algorithm. For instance, an attacker may find it much easier to algorithm. For instance, an attacker may find it much easier to
reproduce the PRNG environment that produced any private keys, reproduce the PRNG environment that produced any private keys,
searching the resulting small set of possibilities, rather than searching the resulting small set of possibilities, rather than
brute-force searching the whole key space. The generation of random brute-force searching the whole key space. The generation of random
numbers of a sufficient level of quality for use in cryptography is numbers of a sufficient level of quality for use in cryptography is
difficult; see Section 3.6.1 of [FIPS204] for some additional difficult; see Section 3.6.1 of [FIPS204] for some additional
information. information.
skipping to change at line 342 skipping to change at line 342
sources: fresh random data generated during signature generation, and sources: fresh random data generated during signature generation, and
precomputed random data included in the signer's private key. This precomputed random data included in the signer's private key. This
is referred to as the "hedged" variant of ML-DSA. Inclusion of both is referred to as the "hedged" variant of ML-DSA. Inclusion of both
sources of random data can help mitigate against faulty random number sources of random data can help mitigate against faulty random number
generators, side-channel attacks, and fault attacks. [FIPS204] also generators, side-channel attacks, and fault attacks. [FIPS204] also
permits creating deterministic signatures using just the precomputed permits creating deterministic signatures using just the precomputed
random data in the signer's private key. The same verification random data in the signer's private key. The same verification
algorithm is used to verify both hedged and deterministic signatures, algorithm is used to verify both hedged and deterministic signatures,
so this choice does not affect interoperability. The signer SHOULD so this choice does not affect interoperability. The signer SHOULD
NOT use the deterministic variant of ML-DSA on platforms where side- NOT use the deterministic variant of ML-DSA on platforms where side-
channel attacks or fault attacks are a concern. Side channel attacks channel attacks or fault attacks are a concern. Side-channel attacks
and fault attacks against ML-DSA are an active area of research and fault attacks against ML-DSA are an active area of research
[WNGD2023] [KPLG2024]. Future protection against these styles of [WNGD2023] [KPLG2024]. Future protection against these styles of
attack may involve interoperable changes to the implementation of ML- attack may involve interoperable changes to the implementation of ML-
DSA's internal functions. Implementers SHOULD consider implementing DSA's internal functions. Implementers SHOULD consider implementing
such protection measures if it would be beneficial for their such protection measures if it would be beneficial for their
particular use cases. particular use cases.
To avoid algorithm substitution attacks, the CMSAlgorithmProtection To avoid algorithm substitution attacks, the CMSAlgorithmProtection
attribute defined in [RFC6211] SHOULD be included in signed attribute defined in [RFC6211] SHOULD be included in signed
attributes. attributes.
 End of changes. 4 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48.