There was a check against the remaining size of the buffer, which used
to be correct, but was broken two commits ago when we started not just
copying the input but also adding to it.
Replace it with a check that the input length is not greater that what's
expected for this step. This guarantees we won't overflow the internal
buffer.
While at it, add an explicit cast to uint8_t when writing the length to
the buffer, so silence an MSVC warning. This cast is safe because we
checked that the length is no larger than 65 or 32 (depending on the
step), so in any case is fits in one byte.
This was found because some lengths had not been adjusted in the test
suite, and instead of failing cleanly, library code performed buffer
overflows. I'll fix the tests in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This macro is specific to the Mbed TLS implementation and not part of
the public API, so it shouldn't used the PSA_ namespace.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The format used by the mbedtls_ecjpake_xxx() APIs and that defined by
the PSA Crypto PAKE extension are quite different; the former is
tailored to the needs of TLS while the later is quite generic and plain.
Previously we only addressed some part of this impedance mismatch: the
different number of I/O rounds, but failed to address the part where the
legacy API adds some extras (length bytes, ECParameters) that shouldn't
be present in the PSA Crypto version. See comments in the code.
Add some length testing as well; would have caught the issue.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
