PSA: EC curve size macro #107

Merged
gilles-peskine-arm merged 2 commits from psa-curve_size_macro into psa-api-1.0-beta 2019-05-16 05:59:42 -05:00
gilles-peskine-arm commented 2019-05-13 13:27:41 -05:00 (Migrated from github.com)

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.

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.
Patater (Migrated from github.com) reviewed 2019-05-15 07:06:50 -05:00
@ -622,2 +622,4 @@
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 );
Patater (Migrated from github.com) commented 2019-05-15 05:42:55 -05:00

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.

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.
gilles-peskine-arm (Migrated from github.com) reviewed 2019-05-15 07:12:49 -05:00
@ -622,2 +622,4 @@
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 );
gilles-peskine-arm (Migrated from github.com) commented 2019-05-15 07:12:49 -05:00

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.

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.
gilles-peskine-arm commented 2019-05-15 17:19:55 -05:00 (Migrated from github.com)

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.

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.
yanesca (Migrated from github.com) approved these changes 2019-05-16 05:00:31 -05:00
yanesca (Migrated from github.com) left a comment

Looks good to me.

Looks good to me.
Patater commented 2019-05-16 05:59:30 -05:00 (Migrated from github.com)

CI failure is ABI job (known to fail until https://github.com/ARMmbed/mbedtls/pull/2636 lands in the development branch) and USE_PSA_CRYPTO, which doesn't work on the API branch.

CI failure is ABI job (known to fail until https://github.com/ARMmbed/mbedtls/pull/2636 lands in the development branch) and USE_PSA_CRYPTO, which doesn't work on the API branch.
Sign in to join this conversation.
No reviewers
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-ARMmbed/mbed-crypto!107
No description provided.