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>
After merging the driver only ECDSA work, a conflict arose between that and
the previous work re-ordering the ciphersuite preference list. We can remove
the breaking requirement on this test, as this requirement is now auto-detected
when the server5 crt is used in the server's command line.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Have clearly separated code to:
* determine whether the assembly-based implementation is available;
* determine whether the intrinsics-based implementation is available;
* select one of the available implementations if any.
Now MBEDTLS_AESNI_HAVE_CODE can be the single interface for aes.c and
aesni.c to determine which AESNI is built.
Change the implementation selection: now, if both implementations are
available, always prefer assembly. Before, the intrinsics were used if
available. This preference is to minimize disruption, and will likely
be revised in a later minor release.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use a single auxiliary function to determine rk_offset, covering both
setkey_enc and setkey_dec, covering both AESNI and PADLOCK. For AESNI, only
build this when using the intrinsics-based implementation, since the
assembly implementation supports unaligned access.
Simplify "do we need to realign?" to "is the desired offset now equal to
the current offset?".
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The padlock feature is enabled if
```
defined(MBEDTLS_PADLOCK_C) && defined(MBEDTLS_HAVE_X86)
```
with the second macro coming from `padlock.h`. The availability of the
macro `MBEDTLS_PADLOCK_ALIGN16` is coincidentally equivalent to
`MBEDTLS_HAVE_X86` but this is not meaningful.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is in preparation for running it multiple times with different
alignments.
This commit also fixes the fact that we weren't calling mbedtls_aes_free()
on the context (we still aren't if the test fails). It's not an issue except
possibly in some ALT implementations.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't use all-bytes zero as a string, it's harder to debug.
This commit uses the test vectors from FIPS 197 appendix C.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
