WIP: Add support for ML-DSA PQC keys#19
WIP: Add support for ML-DSA PQC keys#19stefanberger wants to merge 6 commits intolinux-integrity:next-testingfrom
Conversation
stefanberger
force-pushed
the
mldsa
branch
7 times, most recently
from
1a1ad73 to
b04726b
Compare
stefanberger
force-pushed
the
mldsa
branch
8 times, most recently
from
80459bf to
37929f9
Compare
Disable the following warning to be able to keep the name in a printf string as other functions already do. WARNING: Prefer using '"%s...", __func__' to using 'sign_hash_v1', this function's name, in a string Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
In the imaevm_signhash API, replace the unsized sig parameter array with an expected pointer to an array sig[MAX_SIGNATURE_SIZE - 1]. This conversion at least enforces the correct size for the array for the imaevm_signhash call inside evmctl.c. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
To overcome the limitations of imaevm_signhash API call, implement imaevm_signhash2 that takes a pointer to a buffer pointer for the signature and therefore allows the called function to allocate a buffer. Allocate a buffer if the user provided no buffer or a buffer that is smaller than MAX_SIGNATURE_SIZE - 1. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
force-pushed
the
mldsa
branch
4 times, most recently
from
372ffa0 to
22c8a2b
Compare
|
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?
|
... Also CNSA 2.1 could come out requiring "HashML-DSA" for products created in 202X and later -- if you can maintain backwards compatibility somehow. |
OpenSSL >= v3.5.0 supports signing with ML-DSA-44/65/87. Add support for it to the library. 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 The size of 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. 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>
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>
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. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
|
Latest code push now uses pure-mode ML-DSA. |
2 participants
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.