Re: IMA and PQC

Stefan Berger
2026-02-26T14:16:56Z

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