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>
Document and test the current behavior, even if it is weird:
* For Weierstrass keys, the error is MBEDTLS_ERR_MPI_BUFFER_TOO_SMALL,
not MBEDTLS_ERR_ECP_BUFFER_TOO_SMALL.
* For Weierstrass keys, a smaller output buffer is ok if the output fits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When exporting a key, MBEDTLS_ERR_ECP_FEATURE_UNAVAILABLE should not happen.
This error indicates that the curve is not supported, but that would prevent
the creation of the key.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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>
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>
MBEDTLS_PK_WRITE_C requires MBEDTLS_ASN1_WRITE_C, but there is no
corresponding check in check_config.h. In addition, corresponding
documentation for `Requires` is updated in mbedtls_config.h.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
- check_config.h: combine separate check for MBEDTLS_PK_PARSE_C
- mbedtls_config.h: update documentation for `Requires`
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
In pk.h, MBEDTLS_PK_HAVE_ECC_KEYS is enabled if ECP_C is defined or
USE_PSA_CRYPTO && PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY are defined.
But this logic is duplicate with its definition in
config_adjust_legacy_crypto.h.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
When PK_HAVE_ECC_KEYS is set with PK_[PARSE/WRITE]_C, it needs OID_C
to be enabled. This commit adds proper checks in check_config.h
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
ctx->buflen now returns the amount of valid data in ctx->buf.
Unencrypted buffers were already ok, but encrypted ones were
used to return the length of the encrypted buffer, not the
unencrypted one.
This commit fix this behavior for encrypted buffers.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
ECJPAKE_C only needs MD_LIGHT and it allready auto-enables it in
config_adjust_legacy_crypto.h, so nothing to check here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We're already making sure of that in
include/mbedtls/config_adjust_psa_superset_legacy.h - no need to
double-check here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
After this change, check_config.h does not have any #defined except:
- the standard header double-inclusion guard
- short-lived helpers that are #undef-ed in the same paragraph
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Those were only used for KEY_EXCHANGE_ECJPAKE, but had a much larger
scope than needed. We actually don't need those macros if we distinguish
between cases when expressing dependencies for this key exchange.
The remaining helper macros are all short lived.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It always uses MD now. (The "fall back" to PSA Crypto was only in the
1st iteration of driver-only hash support, before we changed the
architecture to make everything go through MD.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
None of the TLS code is calling low-level hash functions directly. So
the correct dependencies here are MD_CAN.
(I checked and this was the only occurrence.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Simplify: let's take advantage of the MD_CAN macros instead of doing it
again ourselves.
Fix: SHA-3 was forgotten.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Similarly to check_config.h, also build_info.h should consider
MBEDTLS_PSA_CRYPTO_CLIENT as the define which signals that PSA
Crypto APIs feature are being required in the build (possibly
due to the client/service architecture). It is automatically
enabled if CRYPTO_C is enabled, but only at config_adjust_legacy_crypto.h
which happens after the inclusion of the config_psa.h is needed
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
