IMA and PQC

IMA and PQC

[David Howells]

Hi Mimi,

I've posted patches which I hope will accepted to implement ML-DSA module
signing:

	https://lore.kernel.org/linux-crypto/1753972.1769166821@warthog.procyon.org.uk/T/#t

but for the moment, it will give an error to pkcs7_get_digest() if there's no
digest available (which there won't be with ML-DSA).  This means that there
isn't a hash for IMA to get at for TPM measurement.

Now, I probably have to make a SHA256 hash anyway for UEFI blacklisting
purposes, so that could be used.  Alternatively, we can require the use of
authenticatedAttributes/signedAttrs and give you the hash of that - but then
you're a bit at the mercy of whatever hashes were used.

Further, we need to think how we're going to do PQC support in IMA -
particularly as the signatures are so much bigger and verification slower.

Would ML-DSA-44 be acceptable?  Should we grab some internal state out of
ML-DSA to use in lieu of a hash?

David

Re: IMA and PQC

[Mimi Zohar]

On Fri, 2026-01-23 at 17:43 +0000, David Howells wrote:
> Hi Mimi,
> 
> I've posted patches which I hope will accepted to implement ML-DSA module
> signing:
> 
> 	https://lore.kernel.org/linux-crypto/1753972.1769166821@warthog.procyon.org.uk/T/#t
> 
> but for the moment, it will give an error to pkcs7_get_digest() if there's no
> digest available (which there won't be with ML-DSA).  This means that there
> isn't a hash for IMA to get at for TPM measurement.

IMA calculates the file hash for three different purposes: augment the audit
log, extend the TPM, and of course verify the file data signature.

From what I gather there is ML-DSA pure and pre-hash modes.  What you've
implemented is ML-DSA pure mode which passes the data in order to calculate the
file hash, not ML-DSA pre-hash.  For this reason, there is no option to use the
file hash.

> 
> Now, I probably have to make a SHA256 hash anyway for UEFI blacklisting
> purposes, so that could be used.  Alternatively, we can require the use of
> authenticatedAttributes/signedAttrs and give you the hash of that - but then
> you're a bit at the mercy of whatever hashes were used.

Let's discuss alternatives and not jump to the conclusion that you have to break
IMA.

> 
> Further, we need to think how we're going to do PQC support in IMA -
> particularly as the signatures are so much bigger and verification slower.

Perhaps, but these same reasons would apply to kernel modules, firmware, and the
kernel image.  Why would IMA be special?!

> 
> Would ML-DSA-44 be acceptable?  Should we grab some internal state out of
> ML-DSA to use in lieu of a hash?

Is ML-DSA-44 acceptable for kernel modules, firmware, or the kernel image?

Mimi

Re: IMA and PQC

[David Howells]

Mimi Zohar <zohar@linux.ibm.com> wrote:

> > Further, we need to think how we're going to do PQC support in IMA -
> > particularly as the signatures are so much bigger and verification slower.
> 
> Perhaps, but these same reasons would apply to kernel modules, firmware, and
> the kernel image.  Why would IMA be special?!

Scale.  I wouldn't expect more than a couple of hundred or so kernel module
and firmware signatures - and, for the most part, that would be done once
during boot.  On the other hand, I'm assuming that a lot more IMA signatures
might need checking and maybe more frequently.

David

Re: IMA and PQC

[Mimi Zohar]

On Mon, 2026-01-26 at 21:36 +0000, David Howells wrote:
> Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> > > Further, we need to think how we're going to do PQC support in IMA -
> > > particularly as the signatures are so much bigger and verification slower.
> > 
> > Perhaps, but these same reasons would apply to kernel modules, firmware, and
> > the kernel image.  Why would IMA be special?!
> 
> Scale.  I wouldn't expect more than a couple of hundred or so kernel module
> and firmware signatures - and, for the most part, that would be done once
> during boot.  On the other hand, I'm assuming that a lot more IMA signatures
> might need checking and maybe more frequently.

Similarly, most file signatures would be verified on boot and the results cached
to limit the performance impact.  The number of file signatures needing to be
verified is based on policy.

Mimi

Re: IMA and PQC

[Coiby Xu]

Hi David, 

Thanks for starting the discussion on potential issues or challenges for
IMA PQC support!

On Fri, Jan 23, 2026 at 05:43:17PM +0000, David Howells wrote:
>Hi Mimi,
>
>I've posted patches which I hope will accepted to implement ML-DSA module
>signing:
>
>	https://lore.kernel.org/linux-crypto/1753972.1769166821@warthog.procyon.org.uk/T/#t
>
>but for the moment, it will give an error to pkcs7_get_digest() if there's no
>digest available (which there won't be with ML-DSA).  This means that there
>isn't a hash for IMA to get at for TPM measurement.
>
>Now, I probably have to make a SHA256 hash anyway for UEFI blacklisting
>purposes, so that could be used.  Alternatively, we can require the use of
>authenticatedAttributes/signedAttrs and give you the hash of that - but then
>you're a bit at the mercy of whatever hashes were used.

IMA also uses pkcs7_get_digest mainly for the purpose of checking if the
digest has been blacklisted:) So you making a SHA256 hash for UEFI
blacklisting will automatically resolve this issue.

>
>Further, we need to think how we're going to do PQC support in IMA -
>particularly as the signatures are so much bigger and verification slower.

According to my experiments done so far, for verification speed,
ML-DSA-65 is consistently faster than ECDSA P-384 which is used by
current CentOS/RHEL to sign files in a package. 

The size of a single ML-DSA-65 signature indeed increases dramatically
compared with ECDSA P-384 (3309 bytes vs ~100 bytes). But I'm not sure
it can be a big problem when considering the storage capacity. Take
latest fresh CentOS Stream 10 x86_64 KVM guest as example, without any
file system optimization, extra ~189MB disk space is needed if all files
in /usr signed using by ML-DSA-65 where the disk size is 50G. But I
don't have enough experience to tell how users will perceive it and I'll
try to collect more feedback.

For the details of my experiments, you can check
https://gist.github.com/coiby/41cf3a4d59cd64fb19d35b9ac42e4cd7
And here's the tldr; version,
- Verification Speed: ML-DSA-65 is consistently ~10-12% faster
   at verification than ECDSA P-384 when verifying all files in /usr;
   ML-DSA-65 is 2.5x or 3x faster by "openssl speed"

- Signing Speed: ML-DSA-65 appears ~25-30% slower when signing
   all files in /usr; ML-DSA-65 is 4x or 4.8x slower by "openssl speed"

- Storage overhead: For ML-DSA-65, /usr will increase by 189MB and
   430MB when there are 27346 and 58341 files respectively. But total
   size of pure IMA signatures are estimated (files x (3309+20) bytes) to
   be ~87MB and ~185MB respectively.

>Would ML-DSA-44 be acceptable?  Should we grab some internal state out of
>ML-DSA to use in lieu of a hash?

According to 
https://www.ietf.org/archive/id/draft-salter-lamps-cms-ml-dsa-00.html
ML-DSA-44 is intended to meet NIST's level 2 security category. Will
NIST level 2 meet users' security requirements?

>
>David
>
>

-- 
Best regards,
Coiby

Re: IMA and PQC

[David Howells]

Coiby Xu <coxu@redhat.com> wrote:

> Take latest fresh CentOS Stream 10 x86_64 KVM guest as example, without any
> file system optimization, extra ~189MB disk space is needed if all files in
> /usr signed using by ML-DSA-65 where the disk size is 50G.

Is that storing raw signatures rather than PKCS#7 wrapped signatures?

David

Re: IMA and PQC

[Coiby Xu]

On Fri, Jan 30, 2026 at 02:10:21PM +0000, David Howells wrote:
>Coiby Xu <coxu@redhat.com> wrote:
>
>> Take latest fresh CentOS Stream 10 x86_64 KVM guest as example, without any
>> file system optimization, extra ~189MB disk space is needed if all files in
>> /usr signed using by ML-DSA-65 where the disk size is 50G.
>
>Is that storing raw signatures rather than PKCS#7 wrapped signatures?

Yes, it's storing raw signatures + per ~20 bytes overhead including the
4-byte key ID.

>
>David
>

-- 
Best regards,
Coiby

Re: IMA and PQC

[Johannes Wiesböck]

Hi all,

we conducted an evaluation regarding PQC use in IMA last year (see [1] for all
details) where we also considered the interplay of different PQC signatures and
file systems (ext4, btrfs, XFS, f2fs).

Coiby Xu <coxu@redhat.com> wrote:

>According to my experiments done so far, for verification speed,
>ML-DSA-65 is consistently faster than ECDSA P-384 which is used by
>current CentOS/RHEL to sign files in a package. 

Regarding performance, similar to Coiby, we found that all variants of ML-DSA
consistently outperformed ECDSA P-256.

>The size of a single ML-DSA-65 signature indeed increases dramatically
>compared with ECDSA P-384 (3309 bytes vs ~100 bytes). But I'm not sure
>it can be a big problem when considering the storage capacity. Take
>latest fresh CentOS Stream 10 x86_64 KVM guest as example, without any
>file system optimization, extra ~189MB disk space is needed if all files
>in /usr signed using by ML-DSA-65 where the disk size is 50G. But I
>don't have enough experience to tell how users will perceive it and I'll
>try to collect more feedback.
>
>For the details of my experiments, you can check
>https://gist.github.com/coiby/41cf3a4d59cd64fb19d35b9ac42e4cd7
>And here's the tldr; version,
>- Verification Speed: ML-DSA-65 is consistently ~10-12% faster
>   at verification than ECDSA P-384 when verifying all files in /usr;
>   ML-DSA-65 is 2.5x or 3x faster by "openssl speed"
>
>- Signing Speed: ML-DSA-65 appears ~25-30% slower when signing
>   all files in /usr; ML-DSA-65 is 4x or 4.8x slower by "openssl speed"
>
>- Storage overhead: For ML-DSA-65, /usr will increase by 189MB and
>   430MB when there are 27346 and 58341 files respectively. But total
>   size of pure IMA signatures are estimated (files x (3309+20) bytes) to
>   be ~87MB and ~185MB respectively.

Two relevant aspects we discovered regard the signature size. TL;DR:

1. Most file systems need to be tuned to support the larger extended attributes
(signatures) if their size goes above a certain threshold (e.g. enable EA_INODE
in ext4). This influences not only disk usage but overall compatibility between
file systems and PQC signatures. A file system that would not provide the
functionality to store larger extended attributes would be incompatible with
large signatures.

2. For most smaller signatures (like ML-DSA-44/65), we believe that the overhead
of signatures is actually compensated by fragmentation within the file systems.
For example, ext4 will allocate a full file system block for extended attributes.
As long as the signature size is below this block size, we did not observe less
free space on the file system despite the larger signatures.

Overall, we concluded that ML-DSA-65 provides the best combination of disk
overhead, performance and security level. Performace was good and for all
algorithms with larger signatures than ML-DSA-65, file systems would need to be
tuned.

>According to 
>https://www.ietf.org/archive/id/draft-salter-lamps-cms-ml-dsa-00.html
>ML-DSA-44 is intended to meet NIST's level 2 security category. Will
>NIST level 2 meet users' security requirements?

Regarding security levels:
For security levels, we referred to NIST IR 8547 ipd [2].
ECDSA P-256 has a classical security strength of 128bits (P-384: 192bits).
According to [2] Table 3, these levels are met by the different ML-DSA variants.
So, if you are migrating from ECDSA P-384, you need to use at least ML-DSA-65 to
meet the same security strength.

>-- 
>Best regards,
>Coiby

Best regards,
Johannes

[1] https://www.wsbck.net/publications/pqc-ima.pdf
[2] https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

Re: IMA and PQC

[Coiby Xu]

On Fri, Jan 30, 2026 at 09:31:26PM +0100, Johannes Wiesböck wrote:
>Hi all,

Hi Johannes,

>
>we conducted an evaluation regarding PQC use in IMA last year (see [1] for all
>details) where we also considered the interplay of different PQC signatures and
>file systems (ext4, btrfs, XFS, f2fs).

Thanks for sharing this comprehensive study! There are many nuances in
this research paper!

>
>Coiby Xu <coxu@redhat.com> wrote:
>
>>According to my experiments done so far, for verification speed,
>>ML-DSA-65 is consistently faster than ECDSA P-384 which is used by
>>current CentOS/RHEL to sign files in a package.
>
>Regarding performance, similar to Coiby, we found that all variants of ML-DSA
>consistently outperformed ECDSA P-256.

Glad to know ML-DSA is also faster than ECDSA P-256!

>
>>The size of a single ML-DSA-65 signature indeed increases dramatically
>>compared with ECDSA P-384 (3309 bytes vs ~100 bytes). But I'm not sure
>>it can be a big problem when considering the storage capacity. Take
>>latest fresh CentOS Stream 10 x86_64 KVM guest as example, without any
>>file system optimization, extra ~189MB disk space is needed if all files
>>in /usr signed using by ML-DSA-65 where the disk size is 50G. But I
>>don't have enough experience to tell how users will perceive it and I'll
>>try to collect more feedback.
>>
>>For the details of my experiments, you can check
>>https://gist.github.com/coiby/41cf3a4d59cd64fb19d35b9ac42e4cd7
>>And here's the tldr; version,
>>- Verification Speed: ML-DSA-65 is consistently ~10-12% faster
>>   at verification than ECDSA P-384 when verifying all files in /usr;
>>   ML-DSA-65 is 2.5x or 3x faster by "openssl speed"
>>
>>- Signing Speed: ML-DSA-65 appears ~25-30% slower when signing
>>   all files in /usr; ML-DSA-65 is 4x or 4.8x slower by "openssl speed"
>>
>>- Storage overhead: For ML-DSA-65, /usr will increase by 189MB and
>>   430MB when there are 27346 and 58341 files respectively. But total
>>   size of pure IMA signatures are estimated (files x (3309+20) bytes) to
>>   be ~87MB and ~185MB respectively.
>
>Two relevant aspects we discovered regard the signature size. TL;DR:
>
>1. Most file systems need to be tuned to support the larger extended attributes
>(signatures) if their size goes above a certain threshold (e.g. enable EA_INODE
>in ext4). This influences not only disk usage but overall compatibility between
>file systems and PQC signatures. A file system that would not provide the
>functionality to store larger extended attributes would be incompatible with
>large signatures.
>
>2. For most smaller signatures (like ML-DSA-44/65), we believe that the overhead
>of signatures is actually compensated by fragmentation within the file systems.
>For example, ext4 will allocate a full file system block for extended attributes.
>As long as the signature size is below this block size, we did not observe less
>free space on the file system despite the larger signatures.

I think this explains why I didn't see any disk overhead when using ECDSA P-384:)

>
>Overall, we concluded that ML-DSA-65 provides the best combination of disk
>overhead, performance and security level. Performace was good and for all
>algorithms with larger signatures than ML-DSA-65, file systems would need to be
>tuned.

Thanks for summarizing your findings regarding the signature size and
also sharing your evaluation!

>
>>According to
>>https://www.ietf.org/archive/id/draft-salter-lamps-cms-ml-dsa-00.html
>>ML-DSA-44 is intended to meet NIST's level 2 security category. Will
>>NIST level 2 meet users' security requirements?
>
>Regarding security levels:
>For security levels, we referred to NIST IR 8547 ipd [2].
>ECDSA P-256 has a classical security strength of 128bits (P-384: 192bits).
>According to [2] Table 3, these levels are met by the different ML-DSA variants.
>So, if you are migrating from ECDSA P-384, you need to use at least ML-DSA-65 to
>meet the same security strength.

This is helpful info! And thanks for sharing the perspective of
migration!

>
>Best regards,
>Johannes
>
>[1] https://www.wsbck.net/publications/pqc-ima.pdf
>[2] https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
>

-- 
Best regards,
Coiby

Re: IMA and PQC

[Stefan Berger]

On 2/3/26 8:32 AM, Coiby Xu wrote:
> On Fri, Jan 30, 2026 at 09:31:26PM +0100, Johannes Wiesböck wrote:
>> Hi all,
> 
> Hi Johannes,
> 
>>
>> we conducted an evaluation regarding PQC use in IMA last year (see [1] 
>> for all
>> details) where we also considered the interplay of different PQC 
>> signatures and
>> file systems (ext4, btrfs, XFS, f2fs).
> 
> Thanks for sharing this comprehensive study! There are many nuances in
> this research paper!
> 
>>
>> Coiby Xu <coxu@redhat.com> wrote:
>>
>>> According to my experiments done so far, for verification speed,
>>> ML-DSA-65 is consistently faster than ECDSA P-384 which is used by
>>> current CentOS/RHEL to sign files in a package.
>>
>> Regarding performance, similar to Coiby, we found that all variants of 
>> ML-DSA
>> consistently outperformed ECDSA P-256.
> 
> Glad to know ML-DSA is also faster than ECDSA P-256!

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

    Stefan

Re: IMA and PQC

[Eric Biggers]

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.

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.

I'll also note that HashML-DSA is controversial (e.g. see
https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
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.
Which is exactly what we are seeing here, since again, IMA needs to do
the digest calculation and prefixing itself anyway.

- Eric

Re: IMA and PQC

[Stefan Berger]

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

Re: IMA and PQC

[Stefan Berger]

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

Re: IMA and PQC

[Simo Sorce]

On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
> 
> 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.

It is a recommendation, but there are plenty of protocols (TLS,
OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
only, even if what you are signing is not the full data, but something
containing a hash.

Ideally you do not sign *just* a hash, but some structured data, like a
context label that identifies the hash and some other related metadata
for example. In order to make forgeries much harder should the hashing
algorithm used to hash the data weaken over time. But it is not
strictly necessary (NIST mentioned in some forum, sorry I do not have
the message handy for quoting, that a structured packet is perfectly
fine for use with pure ML-DSA, because it does enough to address the
same issues that a separate internal context does with HashML-DSA).

If pure-ML-DSA works better for IMA, just use pure ML-DSA.

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

NIST will not change the standard documents any time soon, but for FIPS
certification there are Implementation Guidelines.

In any case a FIPS module cannot distinguish between data that happens
to be 32 bytes long and a hash of larger data, so the point is kind of
moot. From the FIPS perspective HashML-DSA is just an available
algorithm that protocol implementations can use, or not.

There are additional guidelines on what this may be useful for, but so
far NIST has not objected to the use of pure ML-DSA even where
theoretically HashML-DSA could be used.

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

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

Re: IMA and PQC

[Eric Biggers]

On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
> On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
> > 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.
> 
> It is a recommendation, but there are plenty of protocols (TLS,
> OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
> only, even if what you are signing is not the full data, but something
> containing a hash.
> 
> Ideally you do not sign *just* a hash, but some structured data, like a
> context label that identifies the hash and some other related metadata
> for example. In order to make forgeries much harder should the hashing
> algorithm used to hash the data weaken over time. But it is not
> strictly necessary (NIST mentioned in some forum, sorry I do not have
> the message handy for quoting, that a structured packet is perfectly
> fine for use with pure ML-DSA, because it does enough to address the
> same issues that a separate internal context does with HashML-DSA).
> 
> If pure-ML-DSA works better for IMA, just use pure ML-DSA.
> 
> > 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.
> 
> NIST will not change the standard documents any time soon, but for FIPS
> certification there are Implementation Guidelines.
> 
> In any case a FIPS module cannot distinguish between data that happens
> to be 32 bytes long and a hash of larger data, so the point is kind of
> moot. From the FIPS perspective HashML-DSA is just an available
> algorithm that protocol implementations can use, or not.
> 
> There are additional guidelines on what this may be useful for, but so
> far NIST has not objected to the use of pure ML-DSA even where
> theoretically HashML-DSA could be used.

I see that IMA indeed never upgraded full file hashes to use
'struct ima_file_id'.  Building a new feature that relies on this seems
like a bad idea though, given that it's a security bug that makes the
IMA protocol cryptographically ambiguous.  I.e., it means that in IMA,
when the contents of some file are signed, that signature is sometimes
also valid for some other file contents which the signer didn't intend.

Just fix that bug first, which has to be done anyway.  Then just use
pure ML-DSA to sign and verify the 'struct ima_file_id'.

As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
hash.  It's there as an *option* to solve a perceived problem, which is
actually solvable in better ways.

NIST doesn't plan to update FIPS 204 until 2029, and most likely the
updates will just be errata in the text (such as the ones I reported to
them), not changes or withdrawals in the algorithms themselves.  But
it's irrelevant: just because HashML-DSA is an option doesn't mean it
has to be used.  Pure ML-DSA supports arbitrary data, which includes
formatted hashes which allow for pre-hashing perfectly well.

- Eric

Re: IMA and PQC

[Stefan Berger]

On 2/26/26 11:58 AM, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
>> On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
>>> 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.
>>
>> It is a recommendation, but there are plenty of protocols (TLS,
>> OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
>> only, even if what you are signing is not the full data, but something
>> containing a hash.
>>
>> Ideally you do not sign *just* a hash, but some structured data, like a
>> context label that identifies the hash and some other related metadata
>> for example. In order to make forgeries much harder should the hashing
>> algorithm used to hash the data weaken over time. But it is not
>> strictly necessary (NIST mentioned in some forum, sorry I do not have
>> the message handy for quoting, that a structured packet is perfectly
>> fine for use with pure ML-DSA, because it does enough to address the
>> same issues that a separate internal context does with HashML-DSA).
>>
>> If pure-ML-DSA works better for IMA, just use pure ML-DSA.
>>
>>> 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.
>>
>> NIST will not change the standard documents any time soon, but for FIPS
>> certification there are Implementation Guidelines.
>>
>> In any case a FIPS module cannot distinguish between data that happens
>> to be 32 bytes long and a hash of larger data, so the point is kind of
>> moot. From the FIPS perspective HashML-DSA is just an available
>> algorithm that protocol implementations can use, or not.
>>
>> There are additional guidelines on what this may be useful for, but so
>> far NIST has not objected to the use of pure ML-DSA even where
>> theoretically HashML-DSA could be used.
> 
> I see that IMA indeed never upgraded full file hashes to use
> 'struct ima_file_id'.  Building a new feature that relies on this seems
 > like a bad idea though, given that it's a security bug that makes 
the> IMA protocol cryptographically ambiguous.  I.e., it means that in IMA,
> when the contents of some file are signed, that signature is sometimes
> also valid for some other file contents which the signer didn't intend.

You mean IMA should not sign the digest in the ima_file_id structure but 
hash the ima_file_id structure in which this file digest is written into 
(that we currently sign) and sign/verify this digest? And we would do 
this to avoid two different files (with presumably different content) 
from having the same hashes leading to the same signature? Which hashes 
(besides the non-recommended ones) are so weak now that you must not 
merely sign a file's hash?

The problem with this is that older kernels (without patching) won't be 
able to handle newer signatures.

> 
> Just fix that bug first, which has to be done anyway.  Then just use
> pure ML-DSA to sign and verify the 'struct ima_file_id'.
 > > As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
> hash.  It's there as an *option* to solve a perceived problem, which is
> actually solvable in better ways.
> 
> NIST doesn't plan to update FIPS 204 until 2029, and most likely the
> updates will just be errata in the text (such as the ones I reported to
> them), not changes or withdrawals in the algorithms themselves.  But
> it's irrelevant: just because HashML-DSA is an option doesn't mean it
> has to be used.  Pure ML-DSA supports arbitrary data, which includes

And I was sure whether it was merely an 'option'. Who would use it then 
if it takes more cycles to hash the prepended 11 byte oid in HashML-DSA?

> formatted hashes which allow for pre-hashing perfectly well.
> 
> - Eric

Re: IMA and PQC

[Eric Biggers]

On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
> > I see that IMA indeed never upgraded full file hashes to use
> > 'struct ima_file_id'.  Building a new feature that relies on this seems
> > like a bad idea though, given that it's a security bug that makes the> IMA
> protocol cryptographically ambiguous.  I.e., it means that in IMA,
> > when the contents of some file are signed, that signature is sometimes
> > also valid for some other file contents which the signer didn't intend.
> 
> You mean IMA should not sign the digest in the ima_file_id structure but
> hash the ima_file_id structure in which this file digest is written into
> (that we currently sign) and sign/verify this digest? And we would do this
> to avoid two different files (with presumably different content) from having
> the same hashes leading to the same signature? Which hashes (besides the
> non-recommended ones) are so weak now that you must not merely sign a file's
> hash?
> 
> The problem with this is that older kernels (without patching) won't be able
> to handle newer signatures.

IMA needs to sign the entire ima_file_id structure, which is indeed what
IMA already does when it uses that structure.  (Well, actually it signs
a hash of the struct, but that's best thought of an implementation
detail of legacy signature algorithms that can only sign hashes.  For a
modern algorithm the whole struct should be passed instead.)  Just IMA
uses that structure only for fsverity hashes, which is a bug that makes
the IMA protocol ambiguous.  It needs to use ima_file_id consistently,
otherwise a signed message sometimes corresponds to multiple unique file
contents even without a break in the cryptographic hash function.

Sure, when that bug is fixed, old kernels won't support the new
signatures for files that use a full-file hash.  But the same applies to
starting to use a new signature algorithm, such as ML-DSA.

- Eric

Re: IMA and PQC

[Stefan Berger]

On 2/26/26 1:32 PM, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
>>> I see that IMA indeed never upgraded full file hashes to use
>>> 'struct ima_file_id'.  Building a new feature that relies on this seems
>>> like a bad idea though, given that it's a security bug that makes the> IMA
>> protocol cryptographically ambiguous.  I.e., it means that in IMA,
>>> when the contents of some file are signed, that signature is sometimes
>>> also valid for some other file contents which the signer didn't intend.
>>
>> You mean IMA should not sign the digest in the ima_file_id structure but
>> hash the ima_file_id structure in which this file digest is written into
>> (that we currently sign) and sign/verify this digest? And we would do this
>> to avoid two different files (with presumably different content) from having
>> the same hashes leading to the same signature? Which hashes (besides the
>> non-recommended ones) are so weak now that you must not merely sign a file's
>> hash?
>>
>> The problem with this is that older kernels (without patching) won't be able
>> to handle newer signatures.
> 
> IMA needs to sign the entire ima_file_id structure, which is indeed what
> IMA already does when it uses that structure.  (Well, actually it signs
> a hash of the struct, but that's best thought of an implementation
> detail of legacy signature algorithms that can only sign hashes.  For a
> modern algorithm the whole struct should be passed instead.)  Just IMA
> uses that structure only for fsverity hashes, which is a bug that makes
> the IMA protocol ambiguous.  It needs to use ima_file_id consistently,
> otherwise a signed message sometimes corresponds to multiple unique file
> contents even without a break in the cryptographic hash function.

Before we jump into making changes on this old stuff I think it's good 
to understand the underlying problem and the likelyhood of signatures 
validating different data, such as a file and fsverity data. How likely 
is this?

Assuming a strong hash I suppose that is not a concern with RSA because 
here the digest is padded and then directly encrypted with the private 
key. Upon verification (pub key decrypt) we would unpad and memcmp the 
digests.

Again, assuming a strong hash: With ECDSA NIST P256 for example we have 
a 32 byte signature. With a SHA512 being used for hashing for example we 
would be doing a projection of a 64byte hash space to a 32byte signature 
space with. Just by this projection of a much larger space into a 
smaller space signatures that validate multiple input data could be a 
problem. One 'easy' case where signatures for different input data is 
the same (not exactly the same due to nonce involved the signature is 
verifyable), albeit unlikely, is that there could be different input 
data for the SHA512 that lead to the same 32bytes prefix, which is then 
used after truncating the sha512 to the first 32 bytes for the ECDSA 
signature, and this then leads to a signature that is verifyable for 
different input data. So that's the 'simple' case at least for this 
thought experiment for a non-expert.

Now what should still be difficult to do is given a file and a 
hash-to-use that you can create fsverity content that leads to a hash 
that in turn leads to a NIST-P256 signature that can be used for 
signature verification(s) of the file and the totally different fsverity 
data. Is this a problem that is as difficult to solve just as finding 
different input data for a hash that leads to the same digest?

> 
> Sure, when that bug is fixed, old kernels won't support the new
> signatures for files that use a full-file hash.  But the same applies to
> starting to use a new signature algorithm, such as ML-DSA.
> 
> - Eric
> 

Re: IMA and PQC

[Eric Biggers]

On Thu, Feb 26, 2026 at 02:21:41PM -0500, Stefan Berger wrote:
> 
> 
> On 2/26/26 1:32 PM, Eric Biggers wrote:
> > On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
> > > > I see that IMA indeed never upgraded full file hashes to use
> > > > 'struct ima_file_id'.  Building a new feature that relies on this seems
> > > > like a bad idea though, given that it's a security bug that makes the> IMA
> > > protocol cryptographically ambiguous.  I.e., it means that in IMA,
> > > > when the contents of some file are signed, that signature is sometimes
> > > > also valid for some other file contents which the signer didn't intend.
> > > 
> > > You mean IMA should not sign the digest in the ima_file_id structure but
> > > hash the ima_file_id structure in which this file digest is written into
> > > (that we currently sign) and sign/verify this digest? And we would do this
> > > to avoid two different files (with presumably different content) from having
> > > the same hashes leading to the same signature? Which hashes (besides the
> > > non-recommended ones) are so weak now that you must not merely sign a file's
> > > hash?
> > > 
> > > The problem with this is that older kernels (without patching) won't be able
> > > to handle newer signatures.
> > 
> > IMA needs to sign the entire ima_file_id structure, which is indeed what
> > IMA already does when it uses that structure.  (Well, actually it signs
> > a hash of the struct, but that's best thought of an implementation
> > detail of legacy signature algorithms that can only sign hashes.  For a
> > modern algorithm the whole struct should be passed instead.)  Just IMA
> > uses that structure only for fsverity hashes, which is a bug that makes
> > the IMA protocol ambiguous.  It needs to use ima_file_id consistently,
> > otherwise a signed message sometimes corresponds to multiple unique file
> > contents even without a break in the cryptographic hash function.
> 
> Before we jump into making changes on this old stuff I think it's good to
> understand the underlying problem and the likelyhood of signatures
> validating different data, such as a file and fsverity data. How likely is
> this?
> 
> Assuming a strong hash I suppose that is not a concern with RSA because here
> the digest is padded and then directly encrypted with the private key. Upon
> verification (pub key decrypt) we would unpad and memcmp the digests.
> 
> Again, assuming a strong hash: With ECDSA NIST P256 for example we have a 32
> byte signature. With a SHA512 being used for hashing for example we would be
> doing a projection of a 64byte hash space to a 32byte signature space with.
> Just by this projection of a much larger space into a smaller space
> signatures that validate multiple input data could be a problem. One 'easy'
> case where signatures for different input data is the same (not exactly the
> same due to nonce involved the signature is verifyable), albeit unlikely, is
> that there could be different input data for the SHA512 that lead to the
> same 32bytes prefix, which is then used after truncating the sha512 to the
> first 32 bytes for the ECDSA signature, and this then leads to a signature
> that is verifyable for different input data. So that's the 'simple' case at
> least for this thought experiment for a non-expert.
> 
> Now what should still be difficult to do is given a file and a hash-to-use
> that you can create fsverity content that leads to a hash that in turn leads
> to a NIST-P256 signature that can be used for signature verification(s) of
> the file and the totally different fsverity data. Is this a problem that is
> as difficult to solve just as finding different input data for a hash that
> leads to the same digest?

There's no differentiation between a 'struct ima_file_id' that
*represents* the contents of some file, and a file whose contents are
*equal to* that 'struct ima_file_id' and that uses a full-file hash.  In
both cases the same key and message are used for signing and verifying.

This means that every time a file is signed using the ima_file_id
scheme, it also implicitly signs some other file contents, which an
attacker can freely replace the file with.  Similarly, every time a file
that happens to be a valid ima_file_id is signed using the older scheme,
it also implicitly signs the contents that the ima_file_id correspond
to, which the attacker can freely replace the file with.  In either
case, no collision in the cryptographic hash function is required.

It's simply a broken protocol.  To fix this, IMA must only support
signatures that use the ima_file_id scheme.

Of course, that will require making them support full-file hashes and
not just fsverity hashes.  If I recall correctly, this was actually part
of the original design of the ima_file_id-based signatures.  It's
unclear why the implementation is still incomplete.

- Eric

Re: IMA and PQC

[Stefan Berger]

On 2/26/26 2:44 PM, Eric Biggers wrote:
> On Thu, Feb 26, 2026 at 02:21:41PM -0500, Stefan Berger wrote:
>>
>>
>> On 2/26/26 1:32 PM, Eric Biggers wrote:
>>> On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote:
>>>>> I see that IMA indeed never upgraded full file hashes to use
>>>>> 'struct ima_file_id'.  Building a new feature that relies on this seems
>>>>> like a bad idea though, given that it's a security bug that makes the> IMA
>>>> protocol cryptographically ambiguous.  I.e., it means that in IMA,
>>>>> when the contents of some file are signed, that signature is sometimes
>>>>> also valid for some other file contents which the signer didn't intend.
>>>>
>>>> You mean IMA should not sign the digest in the ima_file_id structure but
>>>> hash the ima_file_id structure in which this file digest is written into
>>>> (that we currently sign) and sign/verify this digest? And we would do this
>>>> to avoid two different files (with presumably different content) from having
>>>> the same hashes leading to the same signature? Which hashes (besides the
>>>> non-recommended ones) are so weak now that you must not merely sign a file's
>>>> hash?
>>>>
>>>> The problem with this is that older kernels (without patching) won't be able
>>>> to handle newer signatures.
>>>
>>> IMA needs to sign the entire ima_file_id structure, which is indeed what
>>> IMA already does when it uses that structure.  (Well, actually it signs
>>> a hash of the struct, but that's best thought of an implementation
>>> detail of legacy signature algorithms that can only sign hashes.  For a
>>> modern algorithm the whole struct should be passed instead.)  Just IMA
>>> uses that structure only for fsverity hashes, which is a bug that makes
>>> the IMA protocol ambiguous.  It needs to use ima_file_id consistently,
>>> otherwise a signed message sometimes corresponds to multiple unique file
>>> contents even without a break in the cryptographic hash function.
>>
>> Before we jump into making changes on this old stuff I think it's good to
>> understand the underlying problem and the likelyhood of signatures
>> validating different data, such as a file and fsverity data. How likely is
>> this?
>>
>> Assuming a strong hash I suppose that is not a concern with RSA because here
>> the digest is padded and then directly encrypted with the private key. Upon
>> verification (pub key decrypt) we would unpad and memcmp the digests.
>>
>> Again, assuming a strong hash: With ECDSA NIST P256 for example we have a 32
>> byte signature. With a SHA512 being used for hashing for example we would be
>> doing a projection of a 64byte hash space to a 32byte signature space with.
>> Just by this projection of a much larger space into a smaller space
>> signatures that validate multiple input data could be a problem. One 'easy'
>> case where signatures for different input data is the same (not exactly the
>> same due to nonce involved the signature is verifyable), albeit unlikely, is
>> that there could be different input data for the SHA512 that lead to the
>> same 32bytes prefix, which is then used after truncating the sha512 to the
>> first 32 bytes for the ECDSA signature, and this then leads to a signature
>> that is verifyable for different input data. So that's the 'simple' case at
>> least for this thought experiment for a non-expert.
>>
>> Now what should still be difficult to do is given a file and a hash-to-use
>> that you can create fsverity content that leads to a hash that in turn leads
>> to a NIST-P256 signature that can be used for signature verification(s) of
>> the file and the totally different fsverity data. Is this a problem that is
>> as difficult to solve just as finding different input data for a hash that
>> leads to the same digest?
> 
> There's no differentiation between a 'struct ima_file_id' that
> *represents* the contents of some file, and a file whose contents are
> *equal to* that 'struct ima_file_id' and that uses a full-file hash.  In
> both cases the same key and message are used for signing and verifying.

I hadn't been thinking of this... It's a side-effect of starting to sign 
ima_file_id for v3 that a file *content* could now hold the ima_file_id 
structure (as signed with v3) and the signature would validate when used 
with the v2 signature verification scheme. So, the content of the file 
would presumably be odd/useless (2 bytes + hash) but it would verify 
with the signature created for v3. We will have to offer the possibility 
to move to v3 signatures for all signing schemes and offer the 
possibility to deactivate older versions (<v3).

> 
> This means that every time a file is signed using the ima_file_id
> scheme, it also implicitly signs some other file contents, which an
> attacker can freely replace the file with.  Similarly, every time a file
> that happens to be a valid ima_file_id is signed using the older scheme,
> it also implicitly signs the contents that the ima_file_id correspond
> to, which the attacker can freely replace the file with.  In either
> case, no collision in the cryptographic hash function is required.
> 
> It's simply a broken protocol.  To fix this, IMA must only support
> signatures that use the ima_file_id scheme.
> 
> Of course, that will require making them support full-file hashes and
> not just fsverity hashes.  If I recall correctly, this was actually part
> of the original design of the ima_file_id-based signatures.  It's
> unclear why the implementation is still incomplete.
> 
> - Eric

Re: IMA and PQC

[Simo Sorce]

On Thu, 2026-02-26 at 12:22 -0500, Stefan Berger wrote:
> 
> On 2/26/26 11:58 AM, Eric Biggers wrote:
> > On Thu, Feb 26, 2026 at 10:27:43AM -0500, Simo Sorce wrote:
> > > On Thu, 2026-02-26 at 09:16 -0500, Stefan Berger wrote:
> > > > 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.
> > > 
> > > It is a recommendation, but there are plenty of protocols (TLS,
> > > OpenPGP, etc...) where the decision has been made to use "pure" ML-DSA
> > > only, even if what you are signing is not the full data, but something
> > > containing a hash.
> > > 
> > > Ideally you do not sign *just* a hash, but some structured data, like a
> > > context label that identifies the hash and some other related metadata
> > > for example. In order to make forgeries much harder should the hashing
> > > algorithm used to hash the data weaken over time. But it is not
> > > strictly necessary (NIST mentioned in some forum, sorry I do not have
> > > the message handy for quoting, that a structured packet is perfectly
> > > fine for use with pure ML-DSA, because it does enough to address the
> > > same issues that a separate internal context does with HashML-DSA).
> > > 
> > > If pure-ML-DSA works better for IMA, just use pure ML-DSA.
> > > 
> > > > 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.
> > > 
> > > NIST will not change the standard documents any time soon, but for FIPS
> > > certification there are Implementation Guidelines.
> > > 
> > > In any case a FIPS module cannot distinguish between data that happens
> > > to be 32 bytes long and a hash of larger data, so the point is kind of
> > > moot. From the FIPS perspective HashML-DSA is just an available
> > > algorithm that protocol implementations can use, or not.
> > > 
> > > There are additional guidelines on what this may be useful for, but so
> > > far NIST has not objected to the use of pure ML-DSA even where
> > > theoretically HashML-DSA could be used.
> > 
> > I see that IMA indeed never upgraded full file hashes to use
> > 'struct ima_file_id'.  Building a new feature that relies on this seems
>  > like a bad idea though, given that it's a security bug that makes 
> the> IMA protocol cryptographically ambiguous.  I.e., it means that in IMA,
> > when the contents of some file are signed, that signature is sometimes
> > also valid for some other file contents which the signer didn't intend.
> 
> You mean IMA should not sign the digest in the ima_file_id structure but 
> hash the ima_file_id structure in which this file digest is written into 
> (that we currently sign) and sign/verify this digest?

You should not (need to) hash it, just format it and the use ML-DSA to
sign it.

> And we would do 
> this to avoid two different files (with presumably different content) 
> from having the same hashes leading to the same signature? Which hashes 
> (besides the non-recommended ones) are so weak now that you must not 
> merely sign a file's hash?
> 
> The problem with this is that older kernels (without patching) won't be 
> able to handle newer signatures.

Ad a kernel option to use the new format? Old kernels won't be able to
deal with ML-DSA IMA either.

> > 
> > Just fix that bug first, which has to be done anyway.  Then just use
> > pure ML-DSA to sign and verify the 'struct ima_file_id'.
>  > > As Simo mentioned, FIPS 204 doesn't require HashML-DSA when signing a
> > hash.  It's there as an *option* to solve a perceived problem, which is
> > actually solvable in better ways.
> > 
> > NIST doesn't plan to update FIPS 204 until 2029, and most likely the
> > updates will just be errata in the text (such as the ones I reported to
> > them), not changes or withdrawals in the algorithms themselves.  But
> > it's irrelevant: just because HashML-DSA is an option doesn't mean it
> > has to be used.  Pure ML-DSA supports arbitrary data, which includes
> 
> And I was sure whether it was merely an 'option'. Who would use it then 
> if it takes more cycles to hash the prepended 11 byte oid in HashML-DSA?

Nobody is using HashML-DSA at the moment.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc