In the 1.0 API some functionality has been split from the
psa_key_derivation_setup() function and is now done with the
psa_key_derivation_input_*() functions. The new tests maintain the
existing test coverage of this functionality.
We want to make the PRF context structure depend on this flag, but
crypto_extra.h is included after crypto_struct.h and having the
option at its original place would not affect crypto_struct.h.
Some key derivation operation contexts (like
psa_tls12_prf_key_derivation_t) directly contain buffers with parts of
the derived key. Erase them safely as part of the abort.
Add the compile time option PSA_PRE_1_0_KEY_DERIVATION. If this is not
turned on, then the function `psa_key_derivation()` is removed.
Most of the tests regarding key derivation haven't been adapted to the
new API yet and some of them have only been adapted partially. When this
new option is turned off, the tests using the old API and test cases
using the old API of partially adapted tests are skipped.
The sole purpose of this option is to make the transition to the new API
smoother. Once the transition is complete it can and should be removed
along with the old API and its implementation.
Remove use of CMAKE_SOURCE_DIR in case mbedtls is built from within
another CMake project. Define MBEDTLS_DIR to ${CMAKE_CURRENT_SOURCE_DIR}
in the main CMakeLists.txt file and refer to that when defining target
include paths to enable mbedtls to be built as a sub project.
Fixes#2609
Signed-off-by: Ashley Duncan <ashes.man@gmail.com>
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
Call `greentea_getc()` 8 times, and then `unhexify` once, instead of
calling `receive_byte()`, which inside calls `greentea_getc()` twice,
for every hex digit.
Since Python3 handles encoding differently than Python2,
a change in the way the data is encoded and sent to the target is needed.
1. Change the test data to be sent as hex string
2. Convert the characters to binary bytes.
This is done because the mbed tools translate the encoding differently
(mbed-greentea, and mbed-htrunner)
From the implementation point of view does not make much difference to
constrain the input order.
We constrain it because, this way the code is easier to review, the data
flow easier to understand and the implementations in general are easier
to validate.
