A number of places lacked the necessary dependencies on one of
the used features: MD, key exchange with certificate,
entropy, or ETM.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
The same elements are now also used when MBEDTLS_USE_PSA_CRYPTO
is defined and respective SHA / MD5 defines are missing.
A new set of macros added in #6065 is used to reflect these dependencies.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
TEST_EQUAL(), has the benefit of outputting the values that don't match,
which can make debugging simpler.
Scope:
- Recently added new test functions
- Checks making sure the test case/data is consistent is out of scope
- Only checks where printing the values is likely to be helpful
Signed-off-by: Janos Follath <janos.follath@arm.com>
MBEDTLS_CMAC_C dependency is ivalid.
"PEM read (unknown encryption algorithm)" needs MBEDTLS_CIPHER_MODE_CBC dependency as
otherwise this test is failing in test_when_no_ciphersuites_have_mac configuration
because mbedtls_pem_read_buffer() returns a different error (MBEDTLS_ERR_PEM_FEATURE_UNAVAILABLE).
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
- Improve test descriptions
- Add more test cases with return value of 1
- Remove the mbedtls prefix from the test function
Signed-off-by: Janos Follath <janos.follath@arm.com>
MBEDTLS_SSL_IANA_TLS_GROUP_SECP192R1 and friends are not members of the mbedtls_ecp_group_id enum
Found by clang's -Wassign-enum
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
This is done to be able to bild test_psa_crypto_config_accel_hash component where MD5 is only available accelerated (PSA_WANT_ALG_MD5 is enabled and MBEDTLS_MD5_C is disabled) but MBEDTLS_USE_PSA_CRYPTO is disabled.
So the build should not attempt to enable pem_pbkdf1.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
- Instead of macros, use direct calculations for array sizes
- Move variable declarations closer to first use
Signed-off-by: Janos Follath <janos.follath@arm.com>
Previously these tests depended on the definition from
inside the MD module, which in turn could be 32 or 64
bytes depending on whether MBEDTLS_SHA512_C was
defined. This is unnecessary, so a constant is itnroduced
instead.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Previously the whole .function file had a global dependency on
MBEDTLS_SHA1_C. This hasn't been correct for a long time:
- on principle, dependency declarations in .function files are for
compile-time dependencies;
- in practice, a number of test cases do not depend on SHA-1, as they only
use SHA-256 or SHA-512 - those cases should not be skipped in builds
without SHA-1;
- this was "taken advantage of" to skip dependency declarations for
test cases that only depended on SHA-1.
The previous commit removed the global dependency on SHA1_C; as a result
the test cases that actually depend on SHA-1 were not skipped in builds
without SHA-1. This commit fixes that by adding dependency declarations
where they belong: in the .data file.
All cases compute hashes using MD is available, or PSA otherwise; so
MD_OR_PSA is appropriate here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
sed -i -f md_or_psa_hash.sed \
tests/suites/test_suite_pkcs1_v21.data
tests/suites/test_suite_pk.data
with md_or_psa_hash.sed containing:
s/MBEDTLS_MD5_C/MBEDTLS_HAS_ALG_MD5_VIA_MD_OR_PSA/g
s/MBEDTLS_RIPEMD160_C/MBEDTLS_HAS_ALG_RIPEMD160_VIA_MD_OR_PSA/g
s/MBEDTLS_SHA1_C/MBEDTLS_HAS_ALG_SHA_1_VIA_MD_OR_PSA/g
s/MBEDTLS_SHA224_C/MBEDTLS_HAS_ALG_SHA_224_VIA_MD_OR_PSA/g
s/MBEDTLS_SHA256_C/MBEDTLS_HAS_ALG_SHA_256_VIA_MD_OR_PSA/g
s/MBEDTLS_SHA384_C/MBEDTLS_HAS_ALG_SHA_384_VIA_MD_OR_PSA/g
s/MBEDTLS_SHA512_C/MBEDTLS_HAS_ALG_SHA_512_VIA_MD_OR_PSA/g
(The only lines in pk.data that still had old-style dependencies where
the ones about PKCS1_V21.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Tests function with various ECP point conditions, covering freshly
initialized, zeroed, non-zero, and freed points.
Signed-off-by: Werner Lewis <werner.lewis@arm.com>
Unfortunately reusing the new function from the signed constant time
comparison is not trivial.
One option would be to do temporary conditional swaps which would prevent
qualifying input to const. Another way would be to add an additional
flag for the sign and make it an integral part of the computation, which
would defeat the purpose of having an unsigned core comparison.
Going with two separate function for now and the signed version can be
retired/compiled out with the legacy API eventually.
The new function in theory could be placed into either
`library/constant_time.c` or `library/bignum_new.c`. Going with the
first as the other functions in the second are not constant time yet and
this distinction seems more valuable for new (as opposed to belonging to
the `_core` functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- We don't check for NULL pointers this deep in the library
- Accessing a NULL pointer when the limb number is 0 as a mistake is the
very similar to any other out of bounds access
- We could potentially mandate at least 1 limb representation for 0 but
we either would need to enforce it or the implementation would be less
robust.
- Allowing zero limb representation - (NULL, 0) in particular - for zero
is present in the legacy interface, if we disallow it, the
compatibility code will need to deal with this (more code size and
opportunities for mistakes)
In summary, interpreting (NULL, 0) as the number zero in the core
interface is the least of the two evils.
Signed-off-by: Janos Follath <janos.follath@arm.com>
