9. Security Considerations

This section preserves the RFC text for X.509 SLH-DSA algorithm identifiers, including ASN.1, OIDs, AlgorithmIdentifier, id-slh-dsa-* and id-hash-slh-dsa-* names, DER examples, certificates, key usage, IANA registrations, and security requirements.

Original RFC Text

9.  Security Considerations

   The security considerations of [RFC5280] apply accordingly.
   Moreover, the security aspects mentioned throughout [FIPS205] should
   be taken into account; for instance, see Sections 3.1 and 3.2 or the
   beginning of Section 11.

   The security of SLH-DSA relies on the security properties of the
   internal hash and XOF functions.  In particular, it relies on these
   functions being preimage resistant, but it does not rely on them
   being collision resistant.  Since HashSLH-DSA performs a pre-hash
   before signing, it relies on both preimage resistance and collision
   resistance of the pre-hash function.  In order to achieve an
   appropriate level of collision resistance, the output length of the
   pre-hash functions used for HashSLH-DSA is twice the length of the
   internal hash and XOF functions.

   Implementations MUST protect the private keys.  Compromise of the
   private keys may result in the ability to forge signatures.

   When generating an SLH-DSA key pair, an implementation MUST generate
   each key pair independently of all other key pairs in the SLH-DSA
   hypertree.

   An SLH-DSA tree MUST NOT be used for more than 2^64 signing
   operations.

   The generation of private keys relies on random numbers.  The use of
   inadequate pseudorandom number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to reproduce the PRNG environment that produced the keys,
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult; see Section 3.1 of [FIPS205] for some
   additional information.

   Fault attacks can lead to forgeries of message signatures; see
   [CMP2018] and [Ge2023].  Verifying a signature before releasing the
   signature value is a typical fault attack countermeasure; however,
   this countermeasure is not effective for SLH-DSA [Ge2023].
   Redundancy by replicating the signature generation process can be
   used as an effective fault attack countermeasure for SLH-DSA
   [Ge2023]; however, the SLH-DSA signature generation is already
   considered slow.

   Likewise, passive power and emissions side-channel attacks can leak
   the SLH-DSA private signing key, and countermeasures can be taken
   against these attacks [SLotH].