Re: IMA and PQC

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
> 
>