ASD ISM 1993 Use pre-hashed ML-DSA variants only when necessary
What it says
Pre-hashed variants of ML-DSA-65 and ML-DSA-87 are only used when the performance of default variants is unacceptable.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnly use alternate ML-DSA signatures if the standard version is too slow.
This control is about using a special kind of digital signature called pre-hashed ML-DSA only when absolutely necessary. Imagine this like using a high-speed blender instead of a regular one only if you're in a rush, because the high-speed one uses more power. If you use it when you don't need to, you might waste resources or even compromise security.
Free. Save your status, tasks and notes.
Why it matters
Using pre-hashed ML-DSA-65/87 without need can add complexity and overhead, without addressing any unacceptable performance limits of default variants.
How to implement
IT team should assess the performance of the standard ML-DSA signature: Check if the speed of the standard version causes any delays or bottlenecks in your systems.
Use performance monitoring tools to determine if the system's responsiveness meets your requirements.
System owner should evaluate necessity for pre-hashed variants: Assess if the regular digital signature method is inadequate for your needs.
Consider if critical processes are slowed down and only switch to pre-hashed versions if these processes cannot otherwise run efficiently.
Manager should oversee a cost-benefit analysis: Determine the trade-offs between using pre-hashed versions and the standard.
Weigh the increased speed against potential risks such as security gaps or resource costs.
Procurement team should ensure software compatibility: Verify that any software acquired supports the use of pre-hashed ML-DSA, should it be required.
Examine technical specifications and consult with vendors during the procurement process.
Security team should implement guidelines around use: Develop guidelines specifying when to use standard versus pre-hashed ML-DSA.
Document scenarios justifying the use of pre-hashed variants to ensure consistent and justified application.
Keep it running
Benchmark default ML-DSA-65/87 in target workflows; only enable pre-hashed variants when measured latency or throughput is unacceptable and documented.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A report on signature algorithm usage: Request documentation that outlines which digital signatures are being used and when.
Look at
Details on decision criteria for using pre-hashed variants.
Good evidence
Will show clear justification when pre-hashed versions are in use.
- Check 2 of 5What an auditor asks for
Ask for
System performance logs: Request logs showing system performance before and after implementing pre-hashed versions. Look to see if there were significant performance improvements without compromising security.
Good evidence
Will show a noticeable improvement that justified the change.
- Check 3 of 5What an auditor asks for
Ask for
Risk assessment reports: Request the organisation's risk assessment associated with using pre-hashed ML-DSA. Look to see if potential risks, like security issues, have been accounted for.
Good evidence
Will include a detailed risk management plan.
- Check 4 of 5What an auditor asks for
Ask for
Cost analysis documentation: Request documentation showing any cost-benefit analysis performed before switching to pre-hashed ML-DSA.
Look at
Consideration of both short-term and long-term impacts.
Good evidence
Includes a balanced analysis justifying the decision.
- Check 5 of 5What an auditor asks for
Ask for
Vendor compatibility confirmations: Request records from vendors confirming compatibility with pre-hashed ML-DSA.
Look at
Documentation such as emails or formal statements from vendors.
Good evidence
Provides clear confirmation from the vendor.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.24.
ISM-1993 requires that pre-hashed ML-DSA-65/87 variants are only used when the performance of the default ML-DSA variants is unacceptable. This relates to Annex A 8.24 because it is a specific rule governing the effective use of cryptography (algorithm/variant selection) within an organisation's cryptographic standards and key management regime. Annex A 8.24 is broader, covering cryptography governance and key management across many algorithms and use cases, whereas ISM-1993 is narrowly focused on when an alternate ML-DSA signing mode is permitted.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.