Re: IMA and PQC

[Mimi Zohar <zohar@linux.ibm.com>]

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