linux-kernel - Re: IMA and PQC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <821cb2becf70b2dcb903e74685643f8b60a5cbb6.camel@linux.ibm.com>
Date: Mon, 26 Jan 2026 16:04:03 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: Simo Sorce <simo@...hat.com>, Roberto Sassu <roberto.sassu@...wei.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Eric Snowberg
 <eric.snowberg@...cle.com>,
        Eric Biggers	 <ebiggers@...nel.org>, linux-integrity@...r.kernel.org,
        linux-crypto@...r.kernel.org, keyrings@...r.kernel.org,
        linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: IMA and PQC

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