New functions are used to cover corner cases:
* authentication data is fed to gcm with 0, 1 or 2 calls to gcm_update
* ciphertext is fed to gcm with 0, 1 or 2 calls to gcm_update_ad
AES-GCM NIST test vectors downloaded at 16.06.2021 from:
csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip
Signed-off-by: Mateusz Starzyk <mateusz.starzyk@mobica.com>
The cipher_bad_order test happened to pass, but was not testing the
failure case it intended to test.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION shifts the location
value (location << 8). This can go outside the range of a 32-bit int
if the location value is above 2^23 as is the case here. Asan
rightfully complained about it. Make the value unsigned to avoid the
integer overflow.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test keys with various persistence levels, enumerated from the
metadata tests.
For read-only keys, do not attempt to create or destroy the key
through the API, only to read a key that has been injected into
storage directly through filesystem access.
Do not test keys with a non-default location, since they require a
driver and we do not yet have a dependency mechanism to require the
presence of a driver for a specific location value.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Attempting to create a key with an invalid location or with read-only
persistence must be rejected.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
Ensure finish only called when encrypting and verify only called for
decrypting, and add tests to ensure this.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Where hashlen was previously ignored when the hash length could be
inferred from an md_alg parameter, the two must now match.
Adapt the existing tests accordingly. Adapt the sample programs accordingly.
This commit does not add any negative testing.
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>
In mbedtls_mpi_read_string, if the string is empty, return an empty bignum
rather than a bignum with one limb with the value 0.
Both representations are correct, so this is not, in principle, a
user-visible change. The change does leak however through
mbedtls_mpi_write_string in base 16 (but not in other bases), as it writes a
bignum with 0 limbs as "" but a bignum with the value 0 and at least one
limb as "00".
This change makes it possible to construct an empty bignum through
mbedtls_mpi_read_string, which is especially useful to construct test
cases (a common use of mbedtls_mpi_read_string, as most formats use in
production encode numbers in binary, to be read with mbedtls_mpi_read_binary
or mbedtls_mpi_read_binary_le).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix mbedtls_mpi_mul_mpi() when one of the operands is zero and the
other is negative. The sign of the result must be 1, since some
library functions do not treat {-1, 0, NULL} or {-1, n, {0}} as
representing the value 0.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a null pointer dereference in mbedtls_mpi_exp_mod(X, A, N, E, _RR) when
A is the value 0 represented with 0 limbs.
Make the code a little more robust against similar bugs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test both 0 represented with 0 limbs ("0 (null)") and 0 represented
with 1 limb ("0 (1 limb)"), because occasionally there are bugs with
0-limb bignums and occasionally there are bugs with removing leading
zero limbs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_mpi_exp_mod can be called in three ways regarding the speed-up
parameter _RR: null (unused), zero (will be updated), nonzero (will be
used). Systematically test all three.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Remove the RR parameter to the mbedtls_mpi_exp_mod test function.
It was never used in the test data, so there is no loss of functionality.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test mbedtls_mpi_safe_cond_assign() and mbedtls_mpi_safe_cond_swap()
with their "unsafe" counterparts mbedtls_mpi_copy() and
mbedtls_mpi_swap(). This way we don't need to repeat the coverage of
test cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
