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] [day] [month] [year] [list]

Message-ID: <20260130203126.662082-1-johannes.wiesboeck@aisec.fraunhofer.de>
Date: Fri, 30 Jan 2026 21:31:26 +0100
From: Johannes Wiesböck <johannes.wiesboeck@...ec.fraunhofer.de>
To: <coxu@...hat.com>
CC: <dhowells@...hat.com>, <dmitry.kasatkin@...il.com>, <ebiggers@...nel.org>,
	<eric.snowberg@...cle.com>, <keyrings@...r.kernel.org>,
	<linux-crypto@...r.kernel.org>, <linux-integrity@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-modules@...r.kernel.org>,
	<roberto.sassu@...wei.com>, <simo@...hat.com>, <zohar@...ux.ibm.com>,
	<michael.weiss@...ec.fraunhofer.de>
Subject: Re: IMA and PQC

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