HashSLH-DSA / HashML-DSA and choice of hash function

[Richard Kettlewell]

Hi folks,

FIPS-205 s10.2 says:

To maintain the same level of security strength when the content
is hashed at the application level or when using the pre-hash
version of SLH-DSA, the digest that is signed needs to be
generated using an approved hash function or XOF (e.g., from FIPS
180-4 or FIPS 202) that provides at least 8n bits of classical
security strength against both collision and second preimage
attacks. Verification of a signature created in this way will
require the verify function to generate a digest from the message
in the same way for input to the verification function.

Is this a requirement on implementations (i.e. 'unbalanced' HashSLH-DSA
is forbidden), or is it just a statement about the necessary conditions
to avoid weakening a HashSLH-DSA parameter set through choice of hash
function (i.e. unbalanced HashSLH-DSA is permitted but not a good idea)?

Are other implementors restricting the (hash, parameter set)
combinations in line with this paragraph?

Does anyone have any reason to use unbalanced HashSLH-DSA, i.e. to
contradict the above paragraph?

There is very similar text in FIPS-204 s5.4, so these questions all
apply to HashML-DSA too.

ttfn/rjk

[Simo Sorce]

On Tue, 2026-01-27 at 23:01 +0000, Richard Kettlewell wrote:
> Does anyone have any reason to use unbalanced HashSLH-DSA, i.e. to
> contradict the above paragraph?

There are situations where a Hash need to be generated for multiple
uses or is generated by a separate module that have other constraints
where there may be a reason to use a less strong hash.

For example a file system may produce SHA-256 hashes of files for
integrity purposes but you want to add actual signatures for some
important files using a module that permits only SLH-DSA-SHA2-256s, for
huge files (say disk images) it may be impractical to recompute
multiple hashes for each use.

Similarly if you need multiple signatures and one of the algorithms
allows only A specific hash of reasonable strength but lower than the
strength of the hash of the signature function.

I see it as a transitional compromise but it is not unusual to see
situation where this happens.

I've seen this with container images where most tooling currently can
only use SHA-256 hashes for content but you want stronger long term
keys for new signatures. Eventually those systems will be adapted to
generate stronger hashes, but in the interim the compromise is better
than no PQC signatures at all.

HTH,
Simo.

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc