Simplify and improve error reporting and remove unnecessary
initialisation (the caller is responsible for initialising those
values).
Signed-off-by: Janos Follath <janos.follath@arm.com>
DEBUG_C supposed to have been removed from the test dependencies, still
being there is an oversight. Removing it was the sole purpose of
3e58109fbd.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The caller is returning MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER if
ssl_parse_signature_algorithm() fails, but
ssl_parse_signature_algorithm() returns
MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE upon failure. There is no good reason
for this mismatch and better to be aligned.
Signed-off-by: Janos Follath <janos.follath@arm.com>
After the recent refactoring ssl_parse_signature_algorithm() sends an
alert on failure, but the caller also sends an alert on failure. Sending
two alerts is at least a protocol violation, and might not leave the SSL
context in a good state.
It is simpler to have the caller read the two bytes, and pass them to
this function.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The unit test framework always loads the client key as well, which
requires a different curve and a hash than the server key.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Add a test case with a successful handshake for each test case that
causes the desired handshake failure, with minimal differences between
the two.
The reason is to have more assurance that the handshake is failing for
the desired reason (as opposed to not having done something correctly in
the test code).
Signed-off-by: Janos Follath <janos.follath@arm.com>
There are other issues that can fail with the same error code. Make sure
that the handshake fails exactly the way we want it to fail by analysing
the client logs.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The logic was easier to follow before 693a47a, which removed the
ssl_parse_signature_algorithm function and introduced the bug being
fixed in this PR.
When validating multiple conditions, it's easier to read, easier to
debug and, as we can see, easier to get right if you validate them
separately.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We usually follow the pattern that a zero-initialised struct is safe to
free. This wasn't the case here.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This root certificate uses SECP-384 and if we don't have it in the
build, the parsing already fails even if we don't try to use it, there
is no reason to have it in the build without the SECP-384.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This bug caused the client accepting sig_algs used by the server that
it explicitly wanted to disallow.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Add tests for key import-export and key import followed by public-key
export when the output buffer is too small. Add these tests for the
following curves:
* p256 as an example of a Weierstrass curve
* Curve25519
* Curve448
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When exporting an FFDH public key we were not properly checking the
length of the output buffer and would write the full length of the key
in all cases. Fix this by checking the size of the output buffer before
we write to it.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This testcase calls psa_export_public_key() on an FFDH key with an
output buffer that is too small. Since the size is calculated based on
the required key size but not checked against the available buffer size,
we overflow the buffer.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
There was a single case for key_agreement_setup that was failing when
setting up the derivation operation. Move this test case to use
derive_setup() instead. Add a corresponding positive test with
derive_setup() to make it more obvious that KEY_AGREEEMENT(ECDH, KDF)
works and the problem really is that the KDF is unknown.
Not the expected_status_setup argument of key_agreement_setup is no
longer needed and can be removed.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
