On Fri, Jan 30, 2026 at 09:31:26PM +0100, Johannes Wiesböck wrote:
Hi all,
Hi Johannes,
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).
Thanks for sharing this comprehensive study! There are many nuances in
this research paper!
Coiby Xu <[email protected]> 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.
Glad to know ML-DSA is also faster than 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.
I think this explains why I didn't see any disk overhead when using ECDSA
P-384:)
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.
Thanks for summarizing your findings regarding the signature size and
also sharing your evaluation!
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.
This is helpful info! And thanks for sharing the perspective of
migration!
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
--
Best regards,
Coiby
