This commit also fixes pk_psa_wrap_sign_ext() setting the RSA padding
mode so that mbedtls_pk_get_psa_attributes() correctly guesses
the PSA alg to be used.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is replaced with: mbedtls_pk_get_psa_attributes() +
mbedtls_pk_import_into_psa() + mbedtls_pk_setup_opaque().
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is replaced with: mbedtls_pk_get_psa_attributes() +
mbedtls_pk_import_into_psa() + mbedtls_pk_setup_opaque().
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Re-restore mbedtls_x509_string_to_names() to public as our example
programs use it, and it is the reverse of mbedtls_x509_dn_gets().
Add a docstring, so that it is a properly documented public function.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Remove the ability to select a custom public exponent via domain parameters
in RSA key generation. The only way to select a custom public exponent is
now to pass custom production parameters to psa_generate_key_ext().
A subsequent commit will remove domain parameters altogether from the API,
thus this commit does not bother to update the documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Static ECDH is of interest to us as developers because it's a generic
scalar multiplication (as opposed to using the standard base point) and
it's useful to have that handy.
For reference the other operations of interest to developers are:
- multiplication of the conventional base point: ECDSA signing is almost
exactly that (just a few field ops on top, notably 1 inversion);
- linear combination: ECDSA verification is almost exactly that too.
Including ephemeral as well, because it's hopefully what's of interest
to most users.
Compared to the previous version, include only one side of the
operations. I don't think including both sides is of interest to anyone.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The setup calls are the only calls to use a key ID.
The key is then copied into the operation object,
all future API calls use the copy instead of the key in the slot.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
The only interaction with key IDs here is in the changed function.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
One can input a key using a key identifier through the two changed functions.
Inputted keys are copied into the operation object.
Any material inputted in byte form is separate to the key slot system.
Outputting a key is threadsafe as per the key loading work.
The verification API is yet to be implemented.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Within setup we create a copy of the key and put it in the operation field.
After setup, we only ever use the new copy,
and do not interact with any key slots.
Therefore we need only register as a reader of the key during setup,
then unregister after we stop accessing the key.
Simultaneous API calls on the same operation object are not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
We copy the key from a slot to the operation object in _start.
_complete and _abort do not access any key slots, instead using
the local copy.
Concurrently using the same operation object is not thread-safe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
