-
Notifications
You must be signed in to change notification settings - Fork 25
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
Custom methods for key generation and key derivation #167
Comments
See Mbed-TLS/mbedtls#8815 for an API proposal (with a prototype implementation). |
On Tuesday 13 Feb 2024, we decided to go ahead with the design in Mbed-TLS/mbedtls#8815 at Mbed-TLS/mbedtls@d8ba2b8 with the change from passing |
A design question came up: if a function takes an input via parameters However, Alternatively, for the current use case, it would make sense for implementations to define a reasonably short What do you think @athoelke ? |
I think that as this has a variable length element, even if the current use cases do not have a wildly varying size, it might be best to categorise this as a 'buffer'-type parameter. This gives the implementation freedom to read-in-place, or to copy-to-cryptoprocessor (or decide at runtime based on the size of the parameter). Note that this is an input parameter, and the calls in which it is used have (aside from the construction parameters):
Therefore, however we classify the construction parameters, it makes no material difference to the behavior of the implementation in terms of 'overlap' or 'stability' - it cannot reasonably overlap with the output key handle (without forcing the compiler to cast pointers), and overlap with other inputs is irrelevant. |
Overlap, no. But stability, yes. The implementation is allowed to assume stability for an input non-buffer (e.g. |
But in this case what does 'assuming stability' look like? For these two APIs, the only agent that might be modifying the buffer while the function is in progress is the application (or something else outside of the implementation) - there is no output parameter that can legally overlap with this input, so the implementation can assume that it will not corrupt this input parameter as a side-effect of its operation. Are we suggesting that the implementation is permitted to be written in a way that might fail badly (i.e. crash, divulge secrets, generate an invalid/insecure key (but report success)) if the data in this parameter content is changed (by the caller) while the function is in progress? I would expect that implementations that do not trust the caller are written to mitigate such misbehavior. |
Perhaps the critical aspect here is that the Maybe ideally, the flags should be treated as a 'stable' parameter, but the data buffer not? On the other hand, we already have an API that mixes control and data within a 'non-stable' parameter: for some key formats used with |
As noted in #194 (comment) and Mbed-TLS/mbedtls#9020, this API is unsupportable in a project that might be included and called from C++ source code. We will have to separate the structure-like parts of the production parameters, from any variable-sized parameters. The suggestion is to rework the API definition to the following:
The unbounded array If This alternative API is now compatible with C++ compilation, but also no longer requires special consideration of whether a parameter is a 'buffer-type parameter'. |
The PSA API should provide ways to customize how key material is created from random or pseudorandom inputs, i.e. key generation and key derivation. The scope here is for customizing the construction of keys (especially cooked keys, i.e. keys that aren't just chosen uniformly among bit-strings of a given length). Here are some possible use cases:
Urgency: Mbed TLS is interested in having a way to generate an RSA key with a chosen public exponent soon. Ideally we would like to include a beta version of this in our next release (code freeze: mid-March), but we don't know whether we'll have time to do the coding even.
My general idea is to define new functions
psa_generate_key_ext()
andpsa_key_derivation_output_key_ext()
(tentative names), which are similar topsa_generate_key()
andpsa_key_derivation_output_key()
but take an extra parameter indicating the custom generation/derivation method. The type of the method parameter has a default value which means the same thing that the non-ext functions do.The text was updated successfully, but these errors were encountered: