In the next refactoring we'll have:
- pretty different paths for N odd or even,
- possibly different paths for A <= 0, in [0, N) or above,
- possibly special cases when A % N is 0 or 1.
Pick two small moduli of different parities (3 and 4)
and go over the range [-(N+1), 2N-1] with A.
This should ensure we naturally run into all special cases.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Use TEST_CALLOC instead of a fixed-size buffer, so that Asan/Valgrind builds
will detect a buffer overflow.
Honor output_size regardless of the value of the number.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Check that the test case is hitting what it's supposed to hit, and that the
library takes the expected defensive measure.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When generated by exp_mod, RR has enough limbs to be passed as a
parameter to core functions. If it is received from the caller, it might
be of any length.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The goal is to test all the bignum's functions that accept a buffer
and its length and verify that they do not crash if a NULL pointer
is passed in as buffer and 0 length is specified.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
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>
