ssl_server2 had a check that we never try to use a minor version lower
than 2 with DTLS, but that check is no longer needed, as there's no way
that would happen now that MBEDTLS_SSL_MINOR_VERSION_1 is no longer
public.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit removes the API
```
mbedtls_ssl_conf_ciphersuites_for_version()
```
which allows to configure lists of acceptable ciphersuites
for each supported version of SSL/TLS: SSL3, TLS 1.{0,1,2}.
With Mbed TLS 3.0, support for SSL3, TLS 1.0 and TLS 1.1
is dropped. Moreover, upcoming TLS 1.3 support has a different
notion of cipher suite and will require a different API.
This means that it's only for TLS 1.2 that we require
a ciphersuite configuration API, and
```
mbedtls_ssl_conf_ciphersuites()
```
can be used for that. The version-specific ciphersuite
configuration API `mbedtls_ssl_conf_ciphersuites_for_version()`,
in turn, is no longer needed.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The idiom "resize an mpi to a given size" appeared 4 times. Unify it
in a single function. Guarantee that the value is set to 0, which is
required by some of the callers and not a significant expense where
not required.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since the internal function mpi_fill_random_internal() assumes that X
has the right size, there is no need to call grow().
To further simplify the function, set the sign outside, and zero out
the non-randomized part directly.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In real life, min << N and the probability that mbedtls_mpi_random()
fails to find a suitable value after 30 iterations is less than one in
a billion. But at least for testing purposes, it's useful to not
outright reject "silly" small values of N, and for such values, 30
iterations is not enough to have a good probability of success.
Pick 250 iterations, which is enough for cases like (min=3, N=4), but
not for cases like (min=255, N=256).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This comment is no longer in the specific context of generating a
random point on an elliptic curve.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_mpi_random() uses mbedtls_mpi_cmp_mpi_ct(), which requires its
two arguments to have the same storage size. This was not the case
when the upper bound passed to mbedtls_mpi_random() had leading zero
limbs.
Fix this by forcing the result MPI to the desired size. Since this is
not what mbedtls_mpi_fill_random() does, don't call it from
mbedtls_mpi_random(), but instead call a new auxiliary function.
Add tests to cover this and other conditions with varying sizes for
the two arguments.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of generating blinding values and keys in a not-quite-uniform way
(https://github.com/ARMmbed/mbedtls/issues/4245) with copy-pasted code,
use mbedtls_mpi_random().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
dhm_make_common includes a piece of code that is identical to
dhm_random_below except for returning a different error code in one
case. Call dhm_random_below instead of repeating the code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
P-1 is as bad as 1 as a blinding value. Don't accept it.
The chance that P-1 would be randomly generated is infinitesimal, so
this is not a practical issue, but it makes the code cleaner. It was
inconsistent to accept P-1 as a blinding value but not as a private key.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Unify the common parts of mbedtls_dhm_make_params and mbedtls_dhm_make_public.
No intended behavior change, except that the exact error code may
change in some corner cases which are too exotic for the existing unit
tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of generating blinding values in a not-quite-uniform way
(https://github.com/ARMmbed/mbedtls/issues/4245) with copy-pasted
code, use mbedtls_mpi_random().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since mbedtls_mpi_random() is not specific to ECC code, move it from
the ECP module to the bignum module.
This increases the code size in builds without short Weierstrass
curves (including builds without ECC at all) that do not optimize out
unused functions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rename mbedtls_ecp_gen_privkey_sw to mbedtls_mpi_random since it has
no particular connection to elliptic curves beyond the fact that its
operation is defined by the deterministic ECDSA specification. This is
a generic function that generates a random MPI between 1 inclusive and
N exclusive.
Slightly generalize the function to accept a different lower bound,
which adds a negligible amount of complexity.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_ecp_gen_privkey_mx generates a random number with a certain
top bit set. Depending on the size, it would either generate a number
with that top bit being random, then forcibly set the top bit to
1 (when high_bit is not a multiple of 8); or generate a number with
that top bit being 0, then set the top bit to 1 (when high_bit is a
multiple of 8). Change it to always generate the top bit randomly
first.
This doesn't make any difference in practice: the probability
distribution is the same either way, and no supported or plausible
curve has a size of the form 8n+1 anyway. But it slightly simplifies
reasoning about the behavior of this function.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't calculate the bit-size of the initially generated random number.
This is not necessary to reach the desired distribution of private
keys, and creates a (tiny) side channel opportunity.
This changes the way the result is derived from the random number, but
does not affect the resulting distribution.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The library rejected an RNG input of all-bits-zero, which led to the
key 2^{254} (for Curve25519) having a 31/32 chance of being generated
compared to other keys. This had no practical impact because the
probability of non-compliance was 2^{-256}, but needlessly
complicated the code.
The exception was added in 98e28a74e3 to
avoid the case where b - 1 wraps because b is 0. Instead, change the
comparison code to avoid calculating b - 1.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For Montgomery keys, n_bits is actually the position of the highest
bit and not the number of bits, which would be 1 more (fence vs
posts). Rename the variable accordingly to lessen the confusion.
No semantic change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Put the Montgomery and short Weierstrass implementations of
mbedtls_ecp_gen_privkey into their own function which can be tested
independently, but will not be part of the public ABI/API.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Prepare to isolate the Montgomery and short Weierstrass
implementations of mbedtls_ecp_gen_privkey into their own function.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When mbedtls_nist_kw_wrap was called with output=NULL and out_size=0, it
performed arithmetic on the null pointer before detecting that the output
buffer is too small and returning an error code. This was unlikely to have
consequences on real-world hardware today, but it is undefined behavior and
UBSan with Clang 10 flagged it. So fix it (fix#4025).
Fix a similar-looking pattern in unwrap, though I haven't verified that it's
reachable there.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
MBEDTLS_ECP_FIXED_POINT_OPTIM aims to speed up ecc multiplication performance.
We compute the comb table in runtime now. It is a costly operation.
This patch add a pre-computed table to initialize well-known curves. It speed up ECDSA signature verify process in runtime by using more ROM size.
Signed-off-by: kXuan <kxuanobj@gmail.com>
The implementation documentation of
```
mbedtls_ssl_tls1_3_derive_early_secrets()
```
mentioned the PSK binder key, which is misleading because the
function doesn't actually calculate it.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
