On 2/26/26 7:42 AM, Stefan Berger wrote:
On 2/25/26 7:10 PM, Eric Biggers wrote:
On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote:
To avoid duplicate work: Is either one of you planning on writing
patches
for IMA to use ML-DSA and convert the current ML-DSA to also support
HashML?
I had done the work on this before and could dig out the patches
again...
IMA already had to add its own digest prefixing support, since it was
needed to disambiguate between full-file digests and fsverity digests.
See 'struct ima_file_id'. Thus the message signed is at most 66 bytes.
The hash there is still only a hash over a file and that hash is signed,
isn't it?
With that being the case, HashML-DSA isn't necessary. It's not even
possible to use here, since there are no OIDs assigned for the fsverity
digests, so it cannot replace the ima_file_id.
For non-fsverify IMA signatures it is 'possible' to use HashML-DSA and
it's 'working' (recycled old patches yesterday):
Linux: https://github.com/stefanberger/linux/commits/
dhmlsa%2Bima.202602025/
ima-evm-utils: https://github.com/linux-integrity/ima-evm-utils/pull/19/
commits
I'll also note that HashML-DSA is controversial (e.g. see
https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
The problem with this is that NIST would have to react to these
controversies as we race to support PQC. If something is wrong with the
standard then it would be best for NIST to withdraw/modify HashML-DSA
asap. Otherwise it's the best to follow the standard IMO because if you
don't you get criticism otherwise.
What I am not clear about from FIPS-204 is whether availability of
HashML-DSA is a "must-use" or a "may-use". What speaks against it for
our use case is performance. The lookup of a hash's ID (last digit of
OID) and the creation of the 11 byte encoding to prepend before every
digest for every signature takes cycles.
Maybe it should explicitly state in FIPS-204 something along the lines
of "with a given hash either ML-DSA or HashML-DSA can be used (for as
long as you use it in the same way from then on)." At least this way
nobody can point out that HashML-DSA should have been used when you didn't.
since it was added to the ML-DSA specification at a late stage without
sufficient review, and what it does can be achieved in better ways.
In case of doubt I would use the standard, though. It's probably not a
good idea for everyone to implement their own (bad) solution.
Which is exactly what we are seeing here, since again, IMA needs to do
the digest calculation and prefixing itself anyway.
Use the standard...
Stefan
- Eric
