After this, only PK, X.509 and TLS remain to be done.
Deterministic uses HMAC-DRBG which uses MD, so it needs crypto_init()
when using a driver-only hash.
Also, remove a special-purpose macro that's no longer needed.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
As a consequence, MD_C is now enabled in component accel_hash_use_psa.
Fix guards in X.509 info function to avoid this causing a failure now.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This enables access to all available hashes, instead of the previous
situation where you had to choose by including MD_C or not.
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>
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>
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>
