PSA: EC curve size macro #107
Conversation
gilles-peskine-arm
added
bug
| @@ -621,6 +621,9 @@ static psa_status_t psa_import_ec_private_key( psa_ecc_curve_t curve, | |||
| mbedtls_ecp_keypair *ecp = NULL; | |||
| mbedtls_ecp_group_id grp_id = mbedtls_ecc_group_of_psa( curve ); | |||
|
|
|||
| if( PSA_BITS_TO_BYTES( PSA_ECC_CURVE_BITS( curve ) ) != data_length ) | |||
| return( PSA_ERROR_INVALID_ARGUMENT ); | |||
There was a problem hiding this comment.
Do we support curves with bit sizes not even multiples of 8? Would we zero-pad within the first or last byte? I looked at export key format, but didn't see the answer, although we do mention endianness.
There was a problem hiding this comment.
Yes (P521). It's zero-padded in the most significant byte, which you know because the spec tells you you have to represent the number in a given number of bits. You know which byte that is because you're told the endianness.
When importing a private elliptic curve key, require the input to have exactly the right size. RFC 5915 requires the right size (you aren't allow to omit leading zeros). A different buffer size likely means that something is wrong, e.g. a mismatch between the declared key type and the actual data.
|
I rebased the PR on top of the target branch. There was an undetected conflict: the test case added in this PR needed to be updated to match the change in the test function in the target branch. |
gilles-peskine-arm
force-pushed
the
psa-curve_size_macro
branch
from
01b6a8c to
c9d910b
Compare
yanesca
added
needs: ci
|
CI failure is ABI job (known to fail until Mbed-TLS/mbedtls#2636 lands in the development branch) and USE_PSA_CRYPTO, which doesn't work on the API branch. |
New macro to get the bit size of an elliptic curve.
Fix a minor bug in private Weierstrass elliptic curve key import whereby a buffer that was too short was accepted and implicitly padded to the left with zeros.