The failure of mbedtls_md was not checked in one place. This could have led
to an incorrect computation if a hardware accelerator failed. In most cases
this would have led to the key exchange failing, so the impact would have been
a hard-to-diagnose error reported in the wrong place. If the two sides of the
key exchange failed in the same way with an output from mbedtls_md that was
independent of the input, this could have led to an apparently successful key
exchange with a predictable key, thus a glitching md accelerator could have
caused a security vulnerability.
This commit allows users to provide alternative implementations of the
ECJPAKE interface through the configuration option MBEDTLS_ECJPAKE_ALT.
When set, the user must add `ecjpake_alt.h` declaring the same
interface as `ecjpake.h`, as well as add some compilation unit which
implements the functionality. This is in line with the preexisting
support for alternative implementations of other modules.
Two causes:
- the buffer is too short (missing 4 bytes for encoding id_len)
- the test was wrong
Would only happen when MBEDTLS_ECP_MAX_BITS == the bitsize of the curve
actually used (does not happen in the default config).
Could not be triggered remotely.
I'm not sure this is necessary, because it is only multiplied by xm2 which is
already random and secret, but OTOH, xm2 is related to a public value, so
let's add blinding with a random value that's only use for blinding, just to
be extra sure.
- reference handshake tests that we get the right values (not much now, but
much more later when we get to deriving the PMS)
- random handshake in addition tests our generate/write functions against our
read functions, that are tested by the reference handshake, and will be
further tested in the test suite later against invalid inputs
