Adds python script for generation of bignum test cases, with initial
classes for mpi_cmp_mpi test cases. Build scripts are updated to
generate test data.
Signed-off-by: Werner Lewis <werner.lewis@arm.com>
test_suite_pk still passes, with the same number of skipped tests as in
the default config minus PKCS#1v2.1
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Currently the test suites are passing because a lot of tests
functions/cases explicitly depend on SHAxxx_C, resulting in them being
skipped in this build. The goal of the next few commits is going to make
them pass and achieve test parity with a non-accelerated build for
selected modules.
Note: compared to the previous component, I'm using 'make tests' not
'make' (ie not building program) because I'm betting build failures
(some header not found) in programs which are not my interest atm.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Add a platform function mbedtls_setbuf(), defaulting to setbuf().
The intent is to allow disabling stdio buffering when reading or writing
files with sensitive data, because this exposes the sensitive data to a
subsequent memory disclosure vulnerability.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Update to a branch with a fix for the test case
"expected error for psa_raw_key_agreement - Small buffer size"
since we just fixed the corresponding bug.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remaining hits seem to be hex data, certificates,
and other miscellaneous exceptions.
List generated by running codespell -w -L
keypair,Keypair,KeyPair,keyPair,ciph,nd
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Remove no_supported HMAC generate/import tests when !PSA_KEY_TYPE_HMAC as HMAC key creation works regardless of PSA_WANT_KEY_TYPE_HMAC.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
component_test_cmake_out_of_source was running the ssl-opt.sh test case
"Fallback SCSV: beginning of list", but this test case was removed in Mbed
TLS 3.0, so ssl-opt.sh was running nothing, which is not an effective test.
In 2.x, the test case was chosen because it uses an additional auxiliary
program tests/scripts/tcp_client.pl. This auxiliary program is no longer
used. So instead, run at least one test case that's sure to exist.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
`PSA_ALG_AEAD_WITH_SHORTENED_TAG(aead_alg, len) == aead_alg` when
`len == PSA_AEAD_TAG_LENGTH(aead_alg)`. So skip this case when testing
the printing of constants.
This fixes one test case due to the way arguments of
`PSA_ALG_AEAD_WITH_SHORTENED_TAG` are enumerated (all algorithms are tested
for a value of `len` which isn't problematic, and all values of `len` are
tested for one algorithm).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
There's nothing wrong with ECC keys on Brainpool curves,
but operations with them are very slow. So we only exercise them
with a single algorithm, not with all possible hashes. We do
exercise other curves with all algorithms so test coverage is
perfectly adequate like this.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
RSA-OAEP requires the key to be larger than a function of the hash size.
Ideally such combinations would be detected as a key/algorithm
incompatibility. However key/algorithm compatibility is currently tested
between the key type and the algorithm without considering the key size, and
this is inconvenient to change. So as a workaround, dispense
OAEP-with-too-small-hash from exercising, without including it in the
automatic operation-failure test generation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In key read tests, add usage flags that are suitable for the key type and
algorithm. This way, the call to exercise_key() in the test not only checks
that exporting the key is possible, but also that operations on the key are
possible.
This triggers a number of failures in edge cases where the generator
generates combinations that are not valid, which will be fixed in subsequent
commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>