Skip to content

Add support for ML-DSA PQC keys#19

Draft
stefanberger wants to merge 16 commits intolinux-integrity:next-testingfrom
stefanberger:mldsa
Draft

Add support for ML-DSA PQC keys#19
stefanberger wants to merge 16 commits intolinux-integrity:next-testingfrom
stefanberger:mldsa

Conversation

@stefanberger
Copy link
Copy Markdown
Contributor

@stefanberger stefanberger commented Jun 27, 2025

This series adds support for ML-DSA PQC key support to the library and evmctl and adds test cases for signing and verifying to the sign_verfiy.test. It requires availability of OpenSSL 3.5.

@stefanberger stefanberger changed the base branch from next to next-testing June 27, 2025 15:12
@stefanberger stefanberger force-pushed the mldsa branch 7 times, most recently from 1a1ad73 to b04726b Compare June 30, 2025 19:51
@stefanberger stefanberger marked this pull request as draft July 1, 2025 21:19
@stefanberger stefanberger force-pushed the mldsa branch 8 times, most recently from 80459bf to 37929f9 Compare July 2, 2025 23:56
@stefanberger stefanberger force-pushed the mldsa branch 4 times, most recently from 372ffa0 to 22c8a2b Compare February 25, 2026 22:30
@coiby
Copy link
Copy Markdown

coiby commented Feb 26, 2026

Hi @stefanberger ,

If I understand the PR correctly, it's actually implementing Pre-Hash ML-DSA. Unfortunately, Currently CNSA 2.0 doesn't allow Pre-Hash ML-DSA,

Q: Is HashML-DSA, aka the pre-hash mode of ML-DSA, allowed in CNSA 2.0?

A: Not at the present time. HashML-DSA is a variant on ML-DSA in FIPS 204, which
describes a method of compressing a message before signing while intentionally
breaking interoperability with ML-DSA to prevent a vulnerability in the case of key re-
use. Because HashML-DSA does not offer any functionality not already offered by the
CNSA hash functions combined in a standard way with ML-DSA-87, and because
standard ML-DSA-87 is expected to be widely supported, NSA anticipates there will be
no need for HashML-DSA in NSS. Hence, at this time, HashML-DSA is not allowed. If at
a later date protocol usage demands it, NSA will provide specific guidance on its limited
usage at that time.

@stefanberger
Copy link
Copy Markdown
Contributor Author

stefanberger commented Feb 26, 2026 •
edited
Loading

Hi @stefanberger ,

If I understand the PR correctly, it's actually implementing Pre-Hash ML-DSA. Unfortunately, Currently CNSA 2.0 doesn't allow Pre-Hash ML-DSA,

Yes, I am actually aware of exactly this and was wondering whether CNSA 2.0 was either incomplete/incorrect, this had to do something with timing of publication versus timing of HashML-DSA addition to standard, or this means that HashML-DSA is optional and ML-DSA can be used also for hashes. So basically this CNSA 2.0 means "forget about HashML-DSA"?? But then CNSA 2.0 is from NSA and HashML-DSA is from NIST. Left hand / right hand problem?

Q: Is HashML-DSA, aka the pre-hash mode of ML-DSA, allowed in CNSA 2.0?
A: Not at the present time. HashML-DSA is a variant on ML-DSA in FIPS 204, which
describes a method of compressing a message before signing while intentionally
breaking interoperability with ML-DSA to prevent a vulnerability in the case of key re-
use. Because HashML-DSA does not offer any functionality not already offered by the
CNSA hash functions combined in a standard way with ML-DSA-87, and because
standard ML-DSA-87 is expected to be widely supported, NSA anticipates there will be
no need for HashML-DSA in NSS. Hence, at this time, HashML-DSA is not allowed. If at
a later date protocol usage demands it, NSA will provide specific guidance on its limited
usage at that time.

@stefanberger
Copy link
Copy Markdown
Contributor Author

stefanberger commented Feb 26, 2026 •
edited
Loading

"A: Not at the present time..."

... Also CNSA 2.1 could come out requiring "HashML-DSA" for products created in 202X and later -- if you can maintain backwards compatibility somehow.

@stefanberger stefanberger force-pushed the mldsa branch 2 times, most recently from a91c745 to fe98da5 Compare February 26, 2026 20:49
@stefanberger
Copy link
Copy Markdown
Contributor Author

stefanberger commented Feb 26, 2026

Latest code push now uses pure-mode ML-DSA.

@stefanberger stefanberger force-pushed the mldsa branch 2 times, most recently from 6d327ef to 261c24b Compare March 4, 2026 16:10
@stefanberger stefanberger force-pushed the mldsa branch 2 times, most recently from 6cbeaf8 to 46d5e69 Compare March 12, 2026 20:12
@stefanberger stefanberger force-pushed the mldsa branch 7 times, most recently from c89f2ed to ab718b9 Compare March 24, 2026 16:21
@stefanberger stefanberger changed the title WIP: Add support for ML-DSA PQC keys Add support for ML-DSA PQC keys Mar 24, 2026
@stefanberger
Use EVP_PKEY_free to free a key of public_key_entry
bb778aa 
Use EVP_PKEY_free to fix a memory leak that occurs when using free() on the
key field of public_key_entry that is a pointer to an EVP_PKEY.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Avoid memory leak if public_keys is NULL
49d78ba 
Avoid a memory leak of a public_key_entry if the passed public_keys
pointer is NULL because in this case the entry is lost. For this particular
case to work we would need public keys to be passed in as
'struct public_key_entry **public_keys' so that '*public_keys = entry'
could be assign. However, this change would propagate all the way to the
API of the library and we don't want to change existing functions'
signature.

This change should not have any noticeable side-effect since the resolved
case did not work before but the newly allocated entry was lost.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Implement imaevm_create_sigv3 for creating V3 signatures
25c3e73 
Implement imaevm_create_sigv3 that creates v3 signatures. This function
will now also allocate a buffer if the caller did not provide one.
Further, it will write the full signature into the signature buffer,
including the leading xattr type byte.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Implement support for IMA signatures V3 signing scheme
7d24e54 
Add support for creating IMA signatures with the V3 signing scheme.
Introduce a global variable that states which signing scheme to
use and for now set it to SIGNATURE_V2. Implement the SIGNATURE_V3
case where necessary for IMA.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Implement support for EVM signatures V3 signing scheme
25caf84 
Add support for creating EVM signatures with the V3 signing scheme.
Implement the SIGNATURE_v3 case where necessary for EVM.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Support v3 IMA and EVM file signatures with --v3 option.
923903a 
Enable both IMA and EVM file signatures with a new --v3 option that sets
the previously introduced global variable that states which signature
version to use.

Similarly, introduce a --v2 option for users to (already) choose old V2
type of signatures.

Update the README with the dump of the evmctl help screen and mention
v3 signature format that is expected for Linux 7.1.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Use imaevm_create_sigv3 for fsverity signature creation
31fc476 
Convert the code that built the fsverity signature with V3 signing scheme
to use the new imaevm_create_sigv3 function.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
tests: Add new --v3 option to sign_verify tests
92003d9 
Add the new --v3 option to the sign_verify test cases.

For --v3, adjust openssl signature verification to build an ima_file_id
structure in a file that is then used for signature verification rather
than the plain file (as before).

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Allow verification of EVM_XATTR_PORTABLE_DIGSIG with sigv3
9475b94 
To enable sigv3 signature verification for EVM portable signatures, allow
signature verification on EVM_XATTR_PORTABLE_DIGSIG type of xattrs
with sigv3.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Allow hashing for sigv3 on EVM_XATTR_PORTABLE_DIGSIG
d804fe1 
To enable sigv3 for EVM portable signatures, enable hashing for sigv3 for
EVM_XATTR_PORTABLE_DIGSIG.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Separator ===================================
b291440 
This patch separates a previous pending PR with this new stuff here.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
checkpatch: Remove warning when function name is found in output string
c872bf1 
Remove the following type of warning:

WARNING: Prefer using '"%s...", __func__' to using 'create_sigv3_mldsa', \
   this function's name, in a string

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
Set size of xattr_value to MAX_SIGNATURE_SIZE
a26795a 
Set the size of an xattr_value that can be read to MAX_SIGNATURE_SIZE
so that ML-DSA keys can also be read once enabled.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger stefanberger force-pushed the mldsa branch 2 times, most recently from 5dfdd1b to 7449997 Compare March 26, 2026 23:54
@stefanberger
Support signing with ML-DSA keys when OpenSSL >=3.5 is available
185e116 
OpenSSL >= v3.5.0 supports signing with ML-DSA-44/65/87. Add support for
it to the imaevm_create_sigv3 library function. Since the ML-DSA signatures
require a lot more space for the signature now, increase the size of the
array where the signatures are stored. The following are the sizes of
ML-DSA signatures by key type:

- ML-DSA-44: 2420
- ML-DSA-65: 3309
- ML-DSA-87: 4627

Prevent signature V2 from being created with any other key types than
'RSA', 'EC', or 'SM2'.

In the functions that created a v2 signature, only RSA, ECDSA, and ECRDSA
signatures are created and they can easily work with the old buffer size of
less than 1024 bytes.

The size availe for extended attributes may be smaller than what is
required by the ML-DSA signature size, and therefore may not be possible
to store for example ML-DSA-87 signatures (depends on type of filesystem).
Nevertheless, extend the MAX_SIGNATURE_SIZE to the required size of
ML-DSA-87 and display an error if writing the signature of a size larger
than 4k did not work.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
examples: Implement script to create ML-DSA-65 CA and signing keys
72ef024 
ima-gen-local-ca-mldsa65.sh creates a CA with an ML-DSA-65 key and
ima-genkey-mldsa65.sh creates an ML-DSA-65 IMA file signing key along with
its certificate.

Also add a script for creating an ML-DSA-87 IMA file signing key. This key
type is good for local testing with the largest possible signature.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
@stefanberger
test: Add tests for signing and verifying with ML-DSA keys
1b92aa0 
Create ML-DSA-44 & ML-DSA-65 keys if ML-DSA-44 can be created with the
installed version of OpenSSL. Add test cases for signing and verifying with
these types of keys.

Do not test with ML-DSA-87 keys since the signatures they create may be
too large for some filesystems' xattrs. On Btrfs, however, it would be
possible to store the large signatures.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@stefanberger @coiby