ctr_drbg is a local variable and thus needs initialisation every time
LLVMFuzzerTestOneInput() is called, the rest of the variables inside the
if(initialised) block are all static.
Add extra validation to attempt to catch this issue in future.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
The non-PSA path has a debug message here, so let's have a similar one
in the PSA case - just add the curve ID to be a bit more informative.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This can be used to validate the server's choice of group in the PSA
case (this will be done in the next commit).
Note that new function doesn't depend on ECP_C, as it only requires
mbedtls_ssl_get_groups(), which is always available. As a general rule,
functions for defining and enforcing policy in the TLS module should not
depend on low-level modules but work with TLS-level identifiers are much
as possible, and this new function follows that principle.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There's no way currently (see below regarding the future) that ECC-based
key exchanges are enabled without ECP_C being defined. So, the #if was
fully redundant with the checks surrounding the function, as it always
evaluated to true.
The situation arose as, in the old days (before Mbed TLS 2.0),
mbedtls_ssl_conf_curves() (or ssl_set_curves() as it was called back
then) was optional, controlled by its own compile-time option
POLARSSL_SSL_SET_CURVES. So, in turn mbedtls_ssl_check_curve() depended
on POLARSSL_SSL_SET_CURVES too, and all calls to it were guarded by
that.
When it was made non-optional, a blind
s/POLARSSL_SSL_SET_CURVES/MBEDTLS_ECP_C/ was done, which resulted in
stupid situations like this with redundant checks for ECP_C.
Note regarding the future: at some point it will be possible to compile
with ECC-based key exchanges but without ECP_C. This doesn't change
anything to the reasoning above: mbedtls_ssl_check_curve() will be
available in all builds where ECC is used; it will just need a new
definition (with new guards), but that doesn't change anything for its
callers.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Initially this function was doing something because the output format of
psa_export_public() didn't match the ECPoint format that TLS wants.
Then it became a no-op then the output format of psa_export_public()
changed, but it made sense to still keep the function in case the format
changed again. Now that the PSA Crypto API has reached 1.0 status, this
is unlikely to happen, so the no-op function is no longer useful.
Removing it de-clutters the code a bit; while at it we can remove a
temporary stack buffer (that was up to 133 bytes).
It's OK to remove this function even if it was declared in a public
header, as there's a warning at the top of the file saying it's not part
of the public API.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
