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>
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>
I ran into a sequence where the assertion `stats[8] > 0` failed for the
range 1..272 with 100 iterations.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Although our build scripts support that, it's annoying, because it makes
"test_suite_XXX" ambiguous between "all the data for
test_suite_XXX.function" and "just test_suite_XXX.data".
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2022-10-21 19:00:38 +02:00
Renamed from tests/suites/test_suite_bignum.data (Browse further)
