In `read_next_b64_code()`, the result of fgetc() is stored into a char,
but later compared against EOF, which is generally -1. On platforms
where char is unsigned, this generates a compiler warning/error that the
comparison will never be true (causing a build failure). The value will
never match, with the function ultimately bailing with a "Too many bad
symbols are detected" error.
On platforms with signed char, EOF is detected, but a file containing a
0xFF character will causes a premature end of file exit of the loop.
Fix this by changing the result to an int.
Fixes#3794.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Signed-off-by: David Brown <david.brown@linaro.org>
The CCM specification (NIST SP 800-38C) mandates that the formatting of
the additional data length l(a) changes when it is greater _or equal_ to
2^16 - 2^8 (>= 0xFF00). Since such lengths are not supported in mbed TLS,
the operation should fail in such cases.
This commit fixes an off-by-one error which allowed encryption/decryption
to be executed when l(a) was equal to 0xFF00, resulting in an
incorrect/non-standard length format being used.
Fixes#3719.
Signed-off-by: Fredrik Strupe <fredrik.strupe@silabs.com>
This reverts commit 9c46a60e6c.
When the library is dynamically linked against Glibc (as is usually
the case with Glibc), it now requires a recent Glibc at runtime if it
was compiled with a recent Glibc. This is a loss of functionality for
no demonstrated benefit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
“Prior to Mbed TLS 2.24” suggests that 2.24 itself didn't use the old
policy anymore, but it did. Change to “Until”, and also give the exact
version number “2.24.0”.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In psa_generate_key_internal() for ECC keys, remove the check that the
bit-size according to Mbed TLS is equal to the requested bit-size.
This check was necessary back when the PSA API encoded curves and key
sizes independently, in order to reject combinations such as SECP256R1
with a 512-bit size. Since the curve encoding changed to specifying a
curve family and a size separately, the Mbed TLS curve id (grp_id) and
the curve data (curve_info) are now determined from the size, and
checking that (curve_info->bit_size == bits) is now only a redundant
sanity check.
This check is actually buggy, because PSA Crypto and Mbed TLS don't
have exactly the same notion of key size. PSA thinks Curve25519 is
255-bit and secp224k1 is 225-bit, but Mbed TLS thinks they're 256-bit
and 224-bit respectively. Removing the check allows key generation to
work for these curves.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_ecp_curve_list() now lists Curve25519 and Curve448 under the names
"x25519" and "x448". These curves support ECDH but not ECDSA.
This was meant ever since the introduction of mbedtls_ecdsa_can_do()
in 0082f9df6f, but
2c69d10bac had removed the claim
that Montgomery curves support ECDH except through Everest.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
From now on, external contributions are no longer acknowledged in the
changelog file. They of course remain acknowledged in the Git history.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Starting with commit 49e94e3, the do/while loop in
`rsa_prepare_blinding()` was changed to a `do...while(0)`, which
prevents retry from being effective and leaves dead code.
Restore the while condition to retry, and lift the calls to finish the
computation out of the while loop by by observing that they are
performed only when `mbedtls_mpi_inv_mod()` returns zero.
Signed-off-by: Peter Kolbus <peter.kolbus@garmin.com>
Python should not be required for the build when the no_test target is
used. This commit adds the generated file to the source tree and the
check-generated-files script, and removes the generation from (c)make.
Fixes#3524
Signed-off-by: Cameron Nemo <cnemo@tutanota.com>
Minor updates to changelog for more concise wording and fixed styling
in other files as needed.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
