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/[email protected]/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
