Both functions are used when MBEDTLS_SSL_SOME_SUITES_USE_MAC is defined not MBEDTLS_SSL_SOME_SUITES_USE_TLS_CBC.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Co-authored-by: Tom Cosgrove <81633263+tom-cosgrove-arm@users.noreply.github.com>
Co-authored-by: Werner Lewis <Werner.Lewis@arm.com>
Signed-off-by: Janos Follath <janos.follath@arm.com>
Numbers:
- A, B for mbedtls_mpi_uint* operands
- a, b for mbedtls_mpi_uint operands
- X or x for result
- HAC references where applicable
Lengths:
- Reserve size or length for length/size in bytes or byte buffers.
- For length of mbedtls_mpi_uint* buffers use limbs
- Length parameters are qualified if possible (eg. input_length or
a_limbs)
Setup functions:
- The parameters match the corresponding structure member's name
- The structure to set up is a standard lower case name even if in other
functions different naming conventions would apply
Scope of changes/conventions:
- bignum_core
- bignum_mod
- bignum_mod_raw
Signed-off-by: Janos Follath <janos.follath@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>
Fix an issue reported by Coverity whereby some constant time functions
called from the ssl decrypt code could potentially access uninitialised
memory.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
