For exponential mod (API mbedtls_mpi_exp_mod) operation, some ESP target
chips needs to have ability for both hardware and software implementation.
Hardware implementation provided performance advantage but it can only
support upto 3072 bit operations (e.g., ESP32-C3) and hence we fallback
to software implementation in such cases (e.g., 4096 bit operations).
Earlier this was handled using linker "--wrap" flag but that does not
work in all scenarios as API `mbedtls_mpi_exp_mod` is being used in
same tranlation (compilation unit).
This approach was found to be next best option with minimal changes in
mbedTLS library.
The function `pk_hashlen_helper` exists to ensure a valid hash_len is
used in pk_verify and pk_sign functions. This function has been
used to adjust to the corrsponding hash_len if the user passes in 0
for the hash_len argument based on the md algorithm given. If the user
does not pass in 0 as the hash_len, then it is not adjusted. This is
problematic if the user gives a hash_len and hash buffer that is less than the
associated length of the md algorithm. This error would go unchecked
and eventually lead to buffer overread when given to specific pk_sign/verify
functions, since they both ignore the hash_len argument if md_alg is not
MBEDTLS_MD_NONE.
This commit, adds a conditional to `pk_hashlen_helper` so that an
error is thrown if the user specifies a hash_length (not 0) and it is
less than the expected for the associated message digest algorithm.
This aligns better with the api documentation where it states "If
hash_len is 0, then the length associated with md_alg is used instead,
or an error returned if it is invalid"
Signed-off-by: Nick Child <nick.child@ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
These macros were moved into a header and now check-names.sh is failing.
Add an MBEDTLS_ prefix to the macro names to make it pass.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Negative x coordinate was tested with the value -1. It happens to be one
of the low order points both for Curve25519 and Curve448 and might be
rejected because of that and not because it is negative. Make sure that
x < 0 is the only plausible reason for the point to be rejected.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We were already rejecting them at the end, due to the fact that with the
usual (x, z) formulas they lead to the result (0, 0) so when we want to
normalize at the end, trying to compute the modular inverse of z will
give an error.
If we wanted to support those points, we'd a special case in
ecp_normalize_mxz(). But it's actually permitted by all sources (RFC
7748 say we MAY reject 0 as a result) and recommended by some to reject
those points (either to ensure contributory behaviour, or to protect
against timing attack when the underlying field arithmetic is not
constant-time).
Since our field arithmetic is indeed not constant-time, let's reject
those points before they get mixed with sensitive data (in
ecp_mul_mxz()), in order to avoid exploitable leaks caused by the
special cases they would trigger. (See the "May the Fourth" paper
https://eprint.iacr.org/2017/806.pdf)
Signed-off-by: Janos Follath <janos.follath@arm.com>
A test case for which the loop would take practically forever if it was
reached. The point would be to validate that the loop is not reached.
The test case should cause the CI to time out if starting with the
current code, ecp_check_pubkey_mx() was changed to call
ecp_check_pubkey_x25519() first and run the mbedtls_mpi_size(() test
afterwards, which would make no semantic difference in terms of memory
contents when the function returns, but would open the way for a DoS.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Clang was complaining and check-names.sh too
This only duplicates macros, so no impact on code size. In 3.0 we can
probably avoid the duplication by using an internal header under
library/ but this won't work for 2.16.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We were already rejecting them at the end, due to the fact that with the
usual (x, z) formulas they lead to the result (0, 0) so when we want to
normalize at the end, trying to compute the modular inverse of z will
give an error.
If we wanted to support those points, we'd a special case in
ecp_normalize_mxz(). But it's actually permitted by all sources
(RFC 7748 say we MAY reject 0 as a result) and recommended by some to
reject those points (either to ensure contributory behaviour, or to
protect against timing attack when the underlying field arithmetic is
not constant-time).
Since our field arithmetic is indeed not constant-time, let's reject
those points before they get mixed with sensitive data (in
ecp_mul_mxz()), in order to avoid exploitable leaks caused by the
special cases they would trigger. (See the "May the Fourth" paper
https://eprint.iacr.org/2017/806.pdf)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The loop exits early iff there is a nonzero limb, so i==0 means that
all limbs are 0, whether the number of limbs is 0 or not.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a bug introduced in "Fix multiplication producing a negative zero" that
caused the sign to be forced to +1 when A > 0, B < 0 and B's low-order limb
is 0.
Add a non-regression test. More generally, systematically test combinations
of leading zeros, trailing zeros and signs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
No need to bypass the API to fill limbs. It's a better test to just
set the top bit that we want to have set, and it's one less bypass of
the API.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
