On Mon, Jan 05, 2026 at 03:21:29PM +0000, David Howells wrote:
The ML-DSA algorithm uses its own internal choice of digest (SHAKE256)
without regard to what's specified in the CMS message. This is, in theory,
configurable, but there's currently no hook in the crypto_sig API to do
that, though possibly it could be done by parameterising the name of the
algorithm, e.g. ("mldsa87(sha512)").
The ML-DSA specification specifies the XOFs used. This has nothing to
do with the API.
quoted hunk ↗ jump to hunk
+config MODULE_SIG_KEY_TYPE_MLDSA_44
+ bool "ML-DSA (Dilithium) 44"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA (Dilithium) 44 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
+
+config MODULE_SIG_KEY_TYPE_MLDSA_65
+ bool "ML-DSA (Dilithium) 65"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA (Dilithium) 65 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
+
+config MODULE_SIG_KEY_TYPE_MLDSA_87
+ bool "ML-DSA (Dilithium) 87"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
Kind of weird naming here. We don't have "AES (Rijndael) 256" and
"SHA-3 (Keccak) 512". We have AES-256 and SHA3-256.
Similarly, these should be ML-DSA-44, etc.
Yes, NIST went with boring names instead of the original cool names.
That's just how it is.
Also unclear why the above help text mentions anything about SHAKE256 or
the authenticatedAttributes. That's an implementation detail. (And the
CMS specification calls them signed attributes anyway.)
- Eric