We have a requirement for a build of our MLDSA implementation which includes signature verification and public key export, but not the signature code (due to code size constraints).
We don't have a way to build the library with exactly this feature set. In principle, you can enable PSA_WANT_KEY_TYPE_ML_DSA_PUBLIC_KEY and disable PSA_WANT_KEY_TYPE_ML_DSA_KEY_PAIR_BASIC to get no support for private keys at all (although this is not supported yet). But as soon as you enable any support for private keys, both the signature code and the verification code will be in the library.
However, if an application doesn't use the signature code, then it should not include the signature code.
To validate this, write sample applications that call the ML-DSA driver wrappers (after #637, they should switch to the ML-DSA API). (We already have similar applications using PK, but PK won't support MLDSA for a while). We need three sample applications: mldsa_export_public (acting on a hard-coded key or a key loaded from a file) or mldsa_generate (generating a random key and exporting both the private key and the public key), mldsa_sign and mldsa_verify. Check the following in at least one all.sh component:
- The combination of the three programs works as expected (
mldsa_sign produces a signature that mldsa_verify accepts, with both programs using the keys produced by mldsa_export_public or mldsa_generate). Use a demo script (programs/*/*_demo.sh).
- Only
mldsa_sign contains signature code. Check that the other programs do not have any of the main functions in mldsa-native that perform a signature (for example, by doing a debug build and listing symbols).
Note that we don't need any sophistication in these applications: no crypto agility, no need to support command line options, etc.
Prerequisites: #633
We have a requirement for a build of our MLDSA implementation which includes signature verification and public key export, but not the signature code (due to code size constraints).
We don't have a way to build the library with exactly this feature set. In principle, you can enable
PSA_WANT_KEY_TYPE_ML_DSA_PUBLIC_KEYand disablePSA_WANT_KEY_TYPE_ML_DSA_KEY_PAIR_BASICto get no support for private keys at all (although this is not supported yet). But as soon as you enable any support for private keys, both the signature code and the verification code will be in the library.However, if an application doesn't use the signature code, then it should not include the signature code.
To validate this, write sample applications that call the ML-DSA driver wrappers (after #637, they should switch to the ML-DSA API). (We already have similar applications using PK, but PK won't support MLDSA for a while). We need three sample applications:
mldsa_export_public(acting on a hard-coded key or a key loaded from a file) ormldsa_generate(generating a random key and exporting both the private key and the public key),mldsa_signandmldsa_verify. Check the following in at least oneall.shcomponent:mldsa_signproduces a signature thatmldsa_verifyaccepts, with both programs using the keys produced bymldsa_export_publicormldsa_generate). Use a demo script (programs/*/*_demo.sh).mldsa_signcontains signature code. Check that the other programs do not have any of the main functions in mldsa-native that perform a signature (for example, by doing a debug build and listing symbols).Note that we don't need any sophistication in these applications: no crypto agility, no need to support command line options, etc.
Prerequisites: #633