The value of the first sent signature algorithm is overwritten.
This test forces only a single algorithm to be sent and then
validates that the client received such algorithm.
04 03 is the expected value for SECP256R1_SHA256.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Fix bug whereby the supported signature algorithm list sent by the
server in the certificate request would not leave enough space for the
length to be written, and thus the first element would get overwritten,
leaving two random bytes in the last entry.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Define the ALLOW_PSK_RESUMPTION and ALLOW_PSK_EPHEMERAL_RESUMPTION
to the key exchange mode EXCHANGE_MODE_PSK and
EXCHANGE_MODE_PSK_EPHEMERAL to facilate later check.
Since they are 1( 1u<<0 ) and 4( 1u<<2 ), so define
ALLOW_EARLY_DATA to 8( 1u<<3 ).
Signed-off-by: Xiaokang Qian <xiaokang.qian@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>
Fix undefined behavior (typically harmless in practice) of
mbedtls_mpi_add_mpi(), mbedtls_mpi_add_abs() and mbedtls_mpi_add_int() when
both operands are 0 and the left operand is represented with 0 limbs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since they're part of the public API (even if only through a few functions),
they should be documented.
I deliberately skipped documenting how to configure the size of the type.
Right now, MBEDTLS_HAVE_INT32 and MBEDTLS_HAVE_INT64 have no Doxygen
documentation, so it's ambiguous whether they're part of the public API.
Resolving this ambiguity is out of scope of my current work.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Although negative zero is officially unsupported, we've had bugs related to
it in the past. So do test functions with a negative zero input.
There will likely be cases where we don't want to accept negative zero as if
it was valid, because it's too hard to handle. We'll add exceptions on a
case by case basis.
For the functions that are currently tested by the generated tests, the new
test cases pass.
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>
In mbedtls_mpi_add_mpi() and mbedtls_mpi_sub_mpi(), and by extention
mbedtls_mpi_add_int() and mbedtls_mpi_sub_int(), when the resulting value
was zero, the sign bit of the result was incorrectly set to -1 when the
left-hand operand was negative. This is not a valid mbedtls_mpi
representation. Fix this: always set the sign to +1 when the result is 0.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This exposes a bug in mbedtls_mpi_add_mpi() and mbedtls_mpi_sub_mpi() which
will be fixed in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_mpi_add_mpi() and mbedtls_mpi_sub_mpi() have the same logic, just
with one bit to flip in the sign calculation. Move the shared logic to a new
auxiliary function. This slightly reduces the code size (if the compiler
doesn't inline) and reduces the maintenance burden.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
