Remove ENABLE_DILITHIUM flag #2082
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2082 +/- ##
==========================================
+ Coverage 78.75% 78.95% +0.20%
==========================================
Files 598 610 +12
Lines 103650 105189 +1539
Branches 14719 14905 +186
==========================================
+ Hits 81625 83050 +1425
- Misses 21371 21486 +115
+ Partials 654 653 -1 ☔ View full report in Codecov by Sentry. |
| } | ||
|
|
||
| /************************************************* | ||
| * Name: crypto_sign_open | ||
| * Name: ml_dsa_verify_message |
There was a problem hiding this comment.
sign_message and verify_message variants are never used (we use sign/verify without the appended message on the end, so that signature sizes are constant)-- should we just remove them from the library?
| @@ -300,7 +300,7 @@ int crypto_sign_signature(ml_dsa_params *params, | |||
| } | |||
|
|
|||
| /************************************************* | |||
| * Name: crypto_sign | |||
| * Name: ml_dsa_sign_message | |||
There was a problem hiding this comment.
sign_message and verify_message variants are never used (we use sign/verify without the appended message on the end, so that signature sizes are constant)-- should we just remove them from the library?
Need to merge #2072 first
Issues:
It's time. (also we need to do this to add ML-DSA to the FIPS module)
Description of changes:
enable_dilithiumflagCall-outs:
Removing the flag has little consequence -- other than it makes the APIs we expose in
include/openssl/evp.hthat much more "final". We should consider how much we like them before we commit to them. We made a point to refer to asymmetric keypairs as public and private keys, rather than public and secret keys. However, we haven't always been consistant with this, so there is a mix of both in the library. Users will find the consistency betweenEVP_PKEY_pqdsa_new_raw_secret_keyandEVP_PKEY_kem_new_raw_secret_keymore satisfying.However, after internal discussions, we'd also like to change the name of
EVP_PKEY_kem_new_raw_public_keyandEVP_PKEY_kem_new_raw_secret_keytoEVP_PKEY_kem_new_raw_encapsulation_keyandEVP_PKEY_kem_new_raw_decapsulation_keyto match the names within FIPS 203. Thus, we should stick withsecret.We did consider the use of an experimental flag (by using the OPENSSL_DEPRECATED alias), but, this seems a little over the top. If there are any discrepancy with the API down the line, we will make a change as we are proposing with the
kemAPIs above. Alternatively, we could place the EVP APIs ininclude/openssl/experimental/. The arguments ofEVP_PKEY_pqdsa_new_raw_secret_key,EVP_PKEY_pqdsa_new_raw_public_key, andEVP_PKEY_CTX_pqdsa_set_paramsare stable and consistant withKEMandECvariants (see EVP_PKEY_CTX_kem_set_params, EVP_PKEY_CTX_set_dh_paramgen_prime_len, and EVP_PKEY_CTX_set_ec_param_enc, EVP_PKEY_new_raw_private_key, EVP_PKEY_new_raw_public_key, EVP_PKEY_kem_new_raw_public_key).Testing:
To celebrate the removal of this flag, enjoy this haiku:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.