mbedtls_dhm_make_params() with x_size != size of P is not likely to be
useful, but it's supported, so test it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Repeat a few tests that use random data. This way the code is
exercised with a few different random values.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Improve the validation of the output from mbedtls_dhm_make_params:
* Test that the output in the byte buffer matches the value in the
context structure.
* Test that the calculated values are in the desired range.
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>
Add unit tests for private key generation on short Weierstrass curves.
These tests validate that the result is within the desired range.
Additionally, they validate that after performing many iterations, the
range is covered to an acceptable extent: for tiny ranges, all values
must be reached; for larger ranges, all value bits must reach both 0
and 1.
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>
Test the exact output from known RNG input. This is overly
constraining, but ensures that the code has good properties.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If a fallback is not explicitly configured in the
mbedtls_test_rnd_buf_info structure, fail after the buffer is
exhausted.
There is no intended behavior change in this commit: all existing uses
of mbedtls_test_rnd_buffer_rand() have been updated to set
mbedtls_test_rnd_std_rand as the fallback.
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>
Zephyr's native posix port define _POSIX_C_SOURCE with a higher value
during the build, so when mbedTLS defines it with a different value
breaks the build.
As Zephyr is already defining a higher value is guaranteed that mbedTLS
required features will be available. So, just define it in case it was
not defined before.
[taken from Zephyr mbedtls module:
76dcd6eeca]
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Signed-off-by: David Brown <david.brown@linaro.org>
Since they became equivalent after moving the is_sign checking back to
the PSA core, they're now redundant, and the generic mac_setup function
can just be called directly.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Since a valid mac operation context would guarantee that the stored
mac size is >= 4, it wasn't immediately obvious that the zero-length
check is meant for static analyzers and a bit of robustness.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
The PSA core checks the key type and algorithm combination before
calling the driver, so the driver doesn't have to do this once more.
The PSA core will also not start an operation with a requested length
which is larger than the full MAC output size, so the output length check
in the driver isn't needed as long as the driver returns an error on
mac_setup if it doesn't support the underlying hash algorithm.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
It makes sense to do the length checking in the core rather than expect
each driver to deal with it themselves. This puts the onus on the core to
dictate which algorithm/key combinations are valid before calling a driver.
Additionally, this commit also updates the psa_mac_sign_finish function
to better deal with output buffer sanitation, as per the review comments
on #4247.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
To avoid the MAC tests from being run when only part of the driver
wrappers (not including MAC) are being configured for test.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
As psa_mac_sign_finish / psa_mac_verify_finish already checks that the
operation structure is valid (id is non-zero), the driver itself doesn't
have to check for that anymore. If the operation has a driver ID assigned,
it means that driver has returned success from its setup function, so the
algorithm value will be set correctly.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
The key passed to the driver has been imported by the PSA Core, meaning
its length has already been verified, and the driver can rely on the
buffer length and key attributes being consistent.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
This means there is no longer a need to have an internal HMAC API, so
it is being removed in this commit as well.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
