Re: IMA and PQC

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.

> 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