Note that ECC key derivation is not using drivers yet, as we don't have driver support for
cooked key derivation acceleration, see
https://github.com/Mbed-TLS/mbedtls/pull/5451 and follow-ups.
So, we still need MBEDTLS_ECP_C enabled at least for this, and probably
in several other places for now.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Fix psa_key_derivation_output_key not being able to derive ECC keys
without MBEDTLS_BUILTIN ECC key types enabled.
The PSA crypto drivers can generate these keys without requiring the
builtin key types.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Same note as previous commit regarding guards.
Note that we could auto-enable MD_LIGHT only when SELF_TEST is defined,
and even only when SHA1_C is defined too, but somewhere down the line
we'll want to auto-enable it for the sake of other RSA function (not in
selftest and could use any hash), so there's little point in optimizing
the temporary condition, let's use the simple one upfront.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
But, for now, still guard things with MBEDTLS_MD5_C, as md.c can only
compute MD5 hashes when MBEDTLS_MD5_C is defined. We'll change the
guards once that has changed.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
On some platforms, including modern Linux, Clang with Msan does not
recognize that explicit_bzero() writes well-defined content to its output
buffer. For us, this causes CMAC operations to fail in Msan builds when
mbedtls_platform_zeroize() is implemented over explicit_bzero(). Fix this.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
All tests that call md_setup() or compute a hash of a HMAC may now need
it in some builds.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The test driver library tries to only build what's necessary, but must
use the same PSA_WANT macros as the main library. So, for things that
are not needed, it undefines MBEDTLS_PSA_BUILTIN_xxx and defines
MBEDTLS_PSA_ACCEL_xxx, unless the ACCEL symbol was defined on the
command line, in which case it undefines it and defineds BUILTIN
instead. This negation happens in crypto_config_test_driver_extension.h
and reflects the fact that what we want accelerated in the main library
is what we want built-in in the driver library (and vice versa if we
want to minimize the size of the driver library).
So, the ACCEL symbols in inside the test driver library (while it's
being built, not those on the command line) are a bit of a white lie:
they don't actually mean "there's an accelerator for this" but instead
"I won't include a built-in for this even though the corresponding
PSA_WANT symbol is defined".
This was quite harmless until MD started making dispatch decisions based
on the ACCEL symbols: when it tries to dispatch to an accelerator that
doesn't actually exist, things tend to go badly.
The minimal fix for this is to change how we enable extra hashes in the
test driver library: by defining the ACCEL symbol on the command line,
in the build we'll end up with the BUILTIN symbol (and implementation!)
and no ACCEL symbol, which is exactly what we want.
Long version: https://arm-ce.slack.com/archives/GTM3SM1K5/p1675071671707599
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- Support for PSA_CRYPTO_CLIENT without PSA_CRYPTO_C is out of scope for
now but might be added later (the architecture supports that).
- While we're using a void pointer for md_ctx, we don't need a union
here; the union will be useful only if & when we remove the indirection.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
