"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>
Instead of passing the size of the whole structure, just pass the data
length and let the implementation worry about adding the size of the
structure. The intent with passing the structure size was to allow
the client code in a client-server implementation to know nothing
about the structure and just copy the bytes to the server. But that was not
really a useful consideration since the application has to know the
structure layout, so it has to be available in the client implementation's
headers. Passing the method data length makes life simpler for everyone by
not having to worry about possible padding at the end of the structure, and
removes a potential error condition
(method_length < sizeof(psa_key_generation_method_t)).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Document proposed additions to the PSA API: psa_generate_key_ext(),
psa_key_derivation_output_key_ext(). For psa_generate_key_ext(), document
the one use case we intend to implement immediately, which is generating an
RSA key with a custom public exponent.
Subsequent commits will implement the documented functionality.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a client view layout (and update related initializers)
for PSA sign/verify hash interruptible operation struct and
PAKE operation struct
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Make sure the layout of psa_key_attributes_s is commented
enough so that it does not accidentally get reorganized
by mistake in the future.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
This function, and mbedtls_psa_crypto_free, are not thread safe as they wipe slots
regardless of state. They are not part of the PSA Crypto API, untrusted applications
cannot call these functions in a crypto service.
In a service intergration, mbedtls_psa_crypto_free on the client cuts the communication
with the crypto service.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Putting the id at the of the psa_key_attributes_s structure allows
for a more efficient marshalling of the parameters around a transport
channel which provides separation between a client view and a service
view of the key parameters.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Any timing variance dependant on the output of this function enables a
Bleichenbacher attack. It is extremely difficult to use safely.
In the Marvin attack paper
(https://people.redhat.com/~hkario/marvin/marvin-attack-paper.pdf) the
author suggests that implementations of PKCS 1.5 decryption that don't
include a countermeasure should be considered inherently dangerous.
They suggest that all libraries implement the same countermeasure, as
implementing different countermeasures across libraries enables the
Bleichenbacher attack as well.
This is extremely fragile and therefore we don't implement it. The use
of PKCS 1.5 in Mbed TLS implements the countermeasures recommended in
the TLS standard (7.4.7.1 of RFC 5246) and is not vulnerable.
Add a warning to PKCS 1.5 decryption to warn users about this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The initializatio macros need to be updated to support the case
where the crypto client view of the structures is being initialized
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
In case MBEDTLS_PSA_CRYPTO_CLIENT is defined and MBEDTLS_PSA_CRYPTO_C
is not, a client view of the multipart operation contexts is provided
through an handle object that allows mapping to the corresponding
service side data structures.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Mbed TLS doesn't support DSA at all, and doesn't support domain parameters
for FFDH (only predefined groups).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move the mbedtls_ecc helper functions from psa_core to psa_util.
These files are not implemented as part of the PSA API and should not
be part of the PSA crypto implementation.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
In PSA headers include psa/build_info.h instead
of mbedtls/build_info.h. In Mbed TLS, both are
equivalent but not in TF-PSA-Crypto where
psa/build_info.h is the correct one.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
We can't have a public header or library file reference our test
environment (except possibly under test-only options, and even so, it would
be with great reluctance). This breaks the build for other people.
Fix#8259.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
