The hash driver entry points (and consequentially the hash driver core)
are now always compiled on when PSA_CRYPTO_DRIVER_TEST is turned on.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
The PSA Core is already calling psa_hash_abort, so the driver doesn't
have to do that explicitly.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Drivers (both built-in and external) need to declare their context
structures in a way such that they are accessible by the
to-be-autogenerated crypto_driver_contexts.h file. That file lives in
include/psa, which means all builtin driver context structure
declarations also need to live in include/psa.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Test hash algorithm functions when called through a transparent
driver in all.sh test_psa_crypto_config_basic and
test_psa_crypto_drivers components.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Apply the right define guards for the right purpose. The 'core' hash
driver is included if any hash algorithm is either to be tested through
the test driver, or if it is requested by a user and not accelerated
(i.e. 'fallback'/'software' driver requested for the algorithm).
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Apparently there's a goal to make the PSA Crypto core free from
dynamic memory allocations. Therefore, all driver context structures
need to be known at compile time in order for the core to know their
final size.
This change defines & implements for hashing operations how the context
structures get defined.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
mac size is previously checked to not be less than 4, so it can't be zero
anymore at this point.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Memsan build was reporting a false positive use of uninitialised memory
in x509_crt.c on a struct filled by an _stat function call. According to
the man pages, the element reported has to be filled in by the call, so
to be safe, and keep memsan happy, zero the struct first.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
When ECDSA is not supported by the library, prefer
to return NOT_SUPPORTED than INVALID_ARGUMENT when
asked for an ECDSA signature.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Move the check that ECDSA is supported from the
caller of the function responsible for Mbed TLS
ECDSA signatures to this function, namely
mbedtls_psa_ecdsa_sign_hash().
This makes the caller code more readable and is
more aligned with what is expected from a
sign_hash() PSA driver entry point.
Add a negative test case where a deterministic
ECDSA signature is requested while the library
does not support deterministic ECDSA.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Reworked the validation of MAC algorithm with the used key type by
introducing psa_mac_key_can_do, which guarantees that PSA_MAC_LENGTH can
be called successfully after validation of the algorithm and key type.
This means psa_get_mac_output_length is no longer required.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Comparing algorithm with its FULL_LENGTH_MAC version doesn't work in
cases where algorithm is a wildcard. Wildcard input is not specified in
the documentation of the function, but in order to test the function
using the same test as PSA_MAC_LENGTH we're mimicking that behaviour here.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Avoid code duplication. Also update the guarantees made by the function
doc to match the guarantees given by PSA_MAC_LENGTH.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
This makes it more in-line with how psa_key_policy_permits works. It
also adds consistency: the intersection of MAC with default length and
MAC with exact-length is now computed correctly in case the exact length
equals the default length of the algorithm when used with the given
key type.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
