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>
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>
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 have two blocks of code to benchmark ECDH. One uses the legacy context
structure, which is only enabled when MBEDTLS_ECP_RESTARTABLE is enabled.
That block doesn't convey any information that's specific to restartable
ECC, it exists only for historical reasons (it came first). The other block
uses only the implementation-agnostic API.
Remove the block that uses the legacy context. It doesn't provide much
extra information and most users won't even see it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
"Key generation method" was misleading since it also applies to key
derivation. Change "key generation" to "key production", which we aren't
using yet and has roughly the right intuition. Change "method" to
"parameters" which there seems to be a slight preference for. Discussion
thread: https://github.com/Mbed-TLS/mbedtls/pull/8815#discussion_r1486524295
Identifiers renamed:
psa_key_generation_method_t → psa_key_production_parameters_t
psa_key_generation_method_s → psa_key_production_parameters_s
PSA_KEY_GENERATION_METHOD_INIT → PSA_KEY_PRODUCTION_PARAMETERS_INIT
method → params
method_data_length → params_data_length
default_method → default_production_parameters
psa_key_generation_method_is_default → psa_key_production_parameters_are_default
setup_key_generation_method → setup_key_production_parameters
key_generation_method_init → key_production_parameters_init
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Assigning the return value of a function that returns a struct with a
flexible array member does not fill the flexible array member, which leaves
a gap in the initialization that could be surprising to programmers. Also,
this is a borderline case in ABI design which could cause interoperability
problems. So remove this function.
This gets rid of an annoying note from GCC about ABI compatibility on
(at least) x86_64.
```
In file included from include/psa/crypto.h:4820,
from <stdin>:1:
include/psa/crypto_struct.h: In function ‘psa_key_generation_method_init’:
include/psa/crypto_struct.h:244:1: note: the ABI of passing struct with a flexible array member has changed in GCC 4.4
244 | {
| ^
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Return MBEDTLS_ERR_PEM_PASSWORD_MISMATCH instead of
MBEDTLS_ERR_PEM_BAD_INPUT_DATA in case of errors.
This commit also fix related failures in test pkparse and
pem test suites.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Now that we have padding verification after decryption and since
this can be used to validate the password as well there is no
need to parse ASN1 content any more, so we can simplify/remove
that dependency.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Remove exception warnings about PKCS1v1.5, since now both padding
formats are treated properly no matter if USE_PSA_CRYPTO is
defined or not.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
