-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add extended key creation functions for non-default production methods #194
Add extended key creation functions for non-default production methods #194
Conversation
For now - marked this as a draft PR. Some rework of the API is required. It turns out that the variable-sized structure definition is not strictly legal in C++, and inclusion and use from C++ is an expected use case for the Crypto API. |
doc/crypto/api.db/psa/crypto.h
Outdated
typedef uint8_t psa_pake_step_t; | ||
typedef struct psa_key_production_parameters_t { | ||
uint32_t flags; | ||
uint8_t data[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yesterday I learned that flexible array members are not standard C++. It is generally expected that C++ compilers can consume C headers, so Mbed TLS and PSA should avoid making headers incompatible with C++.
In Mbed TLS, we'll stay with this API in 3.6.x LTS (too late, it's released), but we'd like to change the API to be C++-compatible in our next major release.
The obvious fix would be to separate the variable-length data out of the struct. This may require a little more RAM in client-server scenarios, but on the bright side it would save the hassle around mixing fixed-format and variable-length data.
ed4a717
to
d074a0f
Compare
d074a0f
to
db30ef6
Compare
Updated in line with the proposal in #167 (comment). This is force-pushed to remove the uneccessary changes to the buffer parameter conventions. The changes between the earlier API in the PR are visible in the single commit db30ef6. |
To support migration for applications using the beta version of this API in Mbed TLS, we need to consider if we can use a different function name for these new APIs. |
Some ideas (including considered and discarded ones) for alternative function names:
Rejected ideas
|
doc/crypto/api.db/psa/crypto.h
Outdated
psa_status_t psa_generate_key_ext(const psa_key_attributes_t *attributes, | ||
const psa_key_production_parameters_t *params, | ||
const uint8_t *params_data, | ||
size_t params_data_length, | ||
mbedtls_svc_key_id_t *key); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Mbed TLS 3.6.1, we want to keep the existing beta psa_generate_key_ext
and psa_key_derivation_output_key_ext
with a psa_key_production_parameters_t*
parameter with a flexible array member, for backward compatibility, and also provide the new C++-compatible type and function with a different name. So we'd like the revised function and type names to be different from the ones in the beta. I propose to go back to “custom”:
psa_status_t psa_generate_key_custom(const psa_key_attributes_t *attributes,
const psa_key_custom_production_t *custom,
const uint8_t *custom_data,
size_t custom_data_length,
mbedtls_svc_key_id_t *key);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the type, psa_key_custom_production_t
or psa_custom_key_production_t
? Both work. It's a custom key production (a key production that's custom), not a custom-key production (a production of a custom key). But custom_key_production
is naturally understood as “custom-key production” which gives the wrong idea. So we lean towards psa_key_custom_production_t
, which is less discoverable but less ambiguous.
doc/crypto/api.db/psa/crypto.h
Outdated
@@ -24,6 +24,9 @@ typedef uint32_t psa_pake_primitive_t; | |||
typedef uint8_t psa_pake_primitive_type_t; | |||
typedef uint8_t psa_pake_role_t; | |||
typedef uint8_t psa_pake_step_t; | |||
typedef struct psa_key_custom_production_t { | |||
uint32_t flags; | |||
} psa_key_custom_production_t; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I'm typing it out, I feel the type name doesn't quite work: this data type doesn't exactly describe a “custom production”, but parameters for a custom production. The name makes me think of an operation context rather than configuration data. So psa_key_custom_parameters_t
feels more natural, or maybe even psa_custom_key_production_parameters_t
(I also feel that the key
part is in a bit of a weird place). But maybe I'm overdoing it with the long descriptive name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind-of thought so too as I worked on the tweaks. My inclination would be to go for psa_custom_key_parameters_t
, rather than more precise-but-long psa_custom_key_production_parameters_t
. Key parameters/attributes are primarily used for key creation in the API, so I think we can get away without 'production' in the name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I've updated Mbed-TLS/mbedtls#9235 to use psa_custom_key_parameters_t
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've updated the PR with this identifier name.
Using a 'custom' infix, to differentitate the API from the beta API deployed in MbedTLS
49cc0ef
to
bde1d2d
Compare
Rebased to sync with main. |
This change has been adopted from Mbed TLS: Mbed-TLS/mbedtls#8815, with changes to make it compatible with C++ compilation.
psa_generate_key_ext()
andpsa_key_derivation_output_key_ext()
, that accept additional parameters to control the key creation process.Notes:
Fixes #167