STDA060 October   2026 MSPM0G3519 , MSPM0G3519-Q1 , MSPM33C321A , MSPM33C321A-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1 Introduction
  5. 2 Security Goals in Embedded Systems
  6. 3 Cryptographic Primitives
  7. 4 The Potential Effects of CRQCs
  8. 5 New Algorithms and Standards for the Future
  9. 6 CNSA Compliance
  10. 7 Symmetric Encryption and Hash Functions
  11. 8 PQC Digital Signatures: ML-DSA
  12. 9 Is Hardware Acceleration Necessary?
  13. 10Is Pre-Hash Necessary?
  14. 11Other NIST-Selected PQC Digital Signature Schemes
  15. 12Stateful Digital Signature Schemes
  16. 13What About Key Agreement?
  17. 14Future-Proofing Embedded Systems
  18. 15References

10 Is Pre-Hash Necessary?

In secure boot implementations, it is common to first hash the application software and firmware image to create a fixed-size message representative using a secure hash function such as SHA-256 or SHA-384, which is then signed and verified through ECDSA. ML-DSA eliminates this "pre-hash" step. In fact, the designers of ML-DSA prefer that users of the scheme pass the entire message content for a digital signature directly into the signature algorithm itself.

In FIPS PUB 204, this process is called "pure" mode. FIPS PUB 204 also defines a pre-hash mode known as HashML-DSA, which includes information about the hash function used in the computation to generate the signature (thus binding the hash function to the signature).

Beyond FIPS 204, it is also possible to employ a third option: pre-hashing the message but signing the hash using ML-DSA in pure mode as if the message was passed directly to ML-DSA, rather than using the pre-hash HashML-DSA mode of FIPS 204. This leaves out the binding of the hash function to the signature, but it is more comparable to how ECDSA is used with SHA today.

ML-DSA uses the Keccak function internally when generating and verifying digital signatures. Keccak is the core function used inside of the SHA-3 function and the SHA and Keccak (Shake) extendable-output function. There are many ways that ML-DSA uses Keccak, including secure digest of the message and deterministic expansion of the public key during verification.

This matters because on resource-constrained systems, the inclusion of ML-DSA means that Keccak is also included, providing a secure hash function within the same code footprint. As a result, using the pure ML-DSA mode of operation means that you do not need to give up additional nonvolatile code memory to store an additional hash function such as SHA-384 or SHA-512. Additionally, Keccak is available for exposing SHA-3 as a general-purpose hash function for other purposes in an application.

At this time, CNSA 2.0-compliant systems can pre-hash a message using an approved secure hash function (SHA-384 or SHA-512) but cannot use ML-DSA in its pre-hash mode (HashML-DSA) as specified in FIPS PUB 204; rather, FIPS PUB 204 pure mode is the default.