We're using the non-standard function strcasecmp() just so that the case
of digits beyond 9 can be different in the library and in the test data.
Use matching case in the test data, and use a standard function for the
comparison.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The random-in-nrange test code has auxiliary functions that are common to all
the interfaces (core, mod_raw (upcoming), mod (upcoming), legacy), and does
some differential testing to check that all the layers consume the RNG in
the saame way. Test them all in the same test suite.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test some cases where mbedtls_mpi_core_random() or mbedtls_mpi_random()
should return MBEDTLS_ERR_MPI_NOT_ACCEPTABLE. These test cases use a very
small range that makes the NOT_ACCEPTABLE case likely. The test code uses a
deterministic RNG whose implementation is in the test framework, so we know
that the tests will pass reproducibly unless the implementation the test
framework changes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test function mpi_random_many() is the main function for testing the
get-random-in-range function. It validates that the random generator's
output is within the desired range, and performs some basic statistical
checks including checking that small ranges are covered exhaustively.
Switch this function from testing mbedtls_mpi_random() to testing
mbedtls_mpi_core_random(). This does not reduce the test coverage of
mbedtls_mpi_random() because the same properties are now validated
indirectly via mpi_random_values() which checks that mbedtls_mpi_random()
and mbedtls_mpi_core_random() produce identical values for identical inputs.
As of this commit, mpi_random_many() still uses some legacy mpi functions
internally because the corresponding functions don't exist yet in core.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For good cases, test that mbedtls_mpi_random() produces the same output as
mbedtls_mpi_core_random().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When x is the most negative value of a two's complement type,
`(unsigned_type)(-x)` has undefined behavior, whereas `-(unsigned_type)x`
has well-defined behavior and does what was intended.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The bignum module does not officially support "negative zero" (an
mbedtls_mpi object with s=-1 and all limbs zero). However, we have a
history of bugs where a function that should produce an official
zero (with s=1), produces a negative zero in some circumstances. So it's
good to check that the bignum functions are robust when passed a negative
zero as input. And for that, we need a way to construct a negative zero
from test case arguments.
There are checks that functions don't produce negative zeros as output in
the test suite. Skip those checks if there's a negative zero input: we
don't want functions to _create_ negative zeros, but we don't mind if
they _propagate_ negative zeros.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Align the name of the bignum test suite with the source module (which was
renamed from mpi.c to bignum.c in the PolarSSL 1.x days). This also brings
it into line with the test suites for the low-level bignum interfaces.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2022-10-21 18:54:43 +02:00
Renamed from tests/suites/test_suite_mpi.function (Browse further)
