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