RSA needs ASN1 functions to parse/write private and public keys,
but there is no guards in the code for that. So we need to enable
ASN1 support whenever RSA is enabled.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Prepare this component for PSA_CRYPTO_CONFIG to be on by default.
Rename it so that the name is still accurate when we remove legacy symbols
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
We actually only need two invocations.
This also moves all the default tests to OPENSSL_NEXT, which is good
because OPENSSL is ancient.
I have no idea why NULL doesn't work with OPENSSL_NEXT (1.1.1a) server,
because according to the manpage [1], "ALL,COMPLEMENTOFALL" (which is
what we are using) should do it, and indeed
$OPENSSL_NEXT ciphers "ALL,COMPLEMENTOFALL" | tr ':' '\n'
lists NULL ciphersuites, and also they work client-side with
OPENSSL_NEXT...
[1] https://www.openssl.org/docs/man1.1.1/man1/ciphers.html
Also, while at it, remove partial invocation (only non-default) from one
component, as we already have a full invocation in the same config (plus
ASan) in another component.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- MBEDTLS_GENPRIME is removed because now we rely on predefined
RSA keys.
- MBEDTLS_RSA_GEN_KEY_MIN_BITS is replaced with RSA_KEY_SIZE which
is set on top of test_suite_pk to a value which is supported
in the predefined_keys[] array.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Remove static declaration of look-up table from test_suite_pk
and generate it automatically with Python.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is to manage RSA and EC keys in the same way in order to
prepare for the following commits.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Most of them (2 exceptions, see below) are of the "driver + built-in"
type, so they're all a subset of test_psa_crypto_driver which tests
everything with driver + built-in at once.
Furthermore, all those components were build-only, while
test_psa_crypto_driver runs the test suites.
Special cases: two of the components looked like they were trying to go for
driver-only (ecdh disabling ECDH_C and hkdf disabling HKDF_C).
For ECDH, built-in would actually be re-enabled because not enough was
accelerated: you also need ECC key types and curves - see
component_test_psa_crypto_config_accel_ecdh which does this correctly.
For HKDF, we don't have test driver support for key derivation yet. I
guess that shows how little testing value these build-only components
really had.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
As the comment says, this component's only goal was to make sure the
legacy+driver test cases in test_suite_md.psa were executed.
But actually these are already executed in
component_test_psa_crypto_drivers which tests with everything having
both a driver and the built-in, as can be seen in the outcomes file.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Was missing several key types and algs. Also, list those that are not
implemented, but comment them out, to make it clearer what's not
implemented yet.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Skipping DTLS 1.2 with old versions was already done, but now properly
test support only once and use the results.
Note that historically, this script's policy was that it's the user's
job to find the right value of -e (EXCLUDE) for their version for
OpenSSL & config. Now it's a weird mix of that and the script doing some
detection and skipping.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
asymmetric_key_data.py already provides EC/RSA key pair values that
are suitable for generate_test_keys.py. So instead of re-generating
the keys using gen_key program, we use those keys.
This commit also:
- extends asymmetric_key_data.py to introduce
RSA bit sizes that are used in test_suite_pk but were missing from
asymmetric_key_data.py.
- updates test_keys.h with new keys.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
We use logical '&&' everywhere, let's be consistent.
(Unless I'm mistaken, binary '&' happens to give the same results for
booleans so this wasn't an actual bug, just style/readability issue.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
