Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better interface to specify the public exponent when generating an RSA key #6494

Closed
gilles-peskine-arm opened this issue Oct 27, 2022 · 0 comments · Fixed by #8815
Closed
Labels
component-crypto Crypto primitives and low-level interfaces enhancement

Comments

@gilles-peskine-arm
Copy link
Contributor

In an early draft of the PSA API, the interface for generating a key was

psa_status_t psa_generate_key(psa_key_slot_t key,
                              psa_key_type_t type,
                              size_t bits,
                              const void *extra,
                              size_t extra_size);

The extra buffer allowed specifying extra parameters with a format that depends on the key type. This was used only for RSA, to specify a different public exponent.

We removed this interface because it violated algorithm agility (the interpretation of extra depends on the key type), and because domain parameters could be used for this purpose. With the benefit of hindsight, domain parameters are a poor fit: the public exponent is redundant on import or copy (with the extra approach, psa_import_key and psa_copy_key don't have an extra parameter), and it isn't useful when querying the attributes with psa_get_key_attributes (if you want to know the public exponent, call psa_export_public_key).

This is currently not an official PSA API. It's a beta API which is being tried out in Mbed TLS. In Mbed TLS, the interface is declared as experimental.

The goal of this task is to define a better interface for specifying the public exponent when generating an RSA key. This may well be a return to the early draft (but with a different function name, e.g. psa_generate_key_ext).

Follow-ups:

  • Implement the new interface and deprecate the use of domain parameters.
  • Remove the use of domain parameters.
@gilles-peskine-arm gilles-peskine-arm added enhancement component-crypto Crypto primitives and low-level interfaces labels Oct 27, 2022
lpy4105 added a commit to lpy4105/mbedtls that referenced this issue Dec 8, 2023
From time being, domain_parameters could not be extracted
from driver. We need to return error to indicate this
situation. This is temporary and would be fixed after Mbed-TLS#6494.

Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
lpy4105 added a commit to lpy4105/mbedtls that referenced this issue Dec 8, 2023
From time being, domain_parameters could not be extracted
from driver. We need to return error to indicate this
situation. This is temporary and would be fixed after Mbed-TLS#6494.

Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
paul-elliott-arm pushed a commit to yanesca/mbedtls that referenced this issue Dec 18, 2023
From time being, domain_parameters could not be extracted
from driver. We need to return error to indicate this
situation. This is temporary and would be fixed after Mbed-TLS#6494.

Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
@minosgalanakis minosgalanakis moved this to Mbed TLS 3.6 release in Past EPICs Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component-crypto Crypto primitives and low-level interfaces enhancement
Projects
Status: Mbed TLS 3.6 release
Development

Successfully merging a pull request may close this issue.

1 participant