PSA: EC curve size macro #107
No reviewers
Labels
No labels
api-spec
bug
CLA requested
CLA valid
compliance
DO NOT MERGE
duplicate
enhancement
feature branch
good first issue
HEADER FORMATTING ISSUE
help wanted
Information
invalid
Jira status: AWAITING REVIEW
Jira status: CLOSED
Jira status: DONE
Jira status: IN PROGRESS
Jira status: IN REVIEW
Jira status: OPEN
Jira status: REOPENED
Jira status: RESOLVED
mirrored
mirror internally
needs: backports
needs: ci
needs: design review
needs: preceding PR
needs: review
needs: work
notabug
open for community contribution
Product Backlog
question
ready for merge
security
stale
type: bug
type: enhancement
type: question
web pages
wontfix
writing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-ARMmbed/mbed-crypto!107
Loading…
Reference in a new issue
No description provided.
Delete branch "psa-curve_size_macro"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@ -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 );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.
@ -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 );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.
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.
Looks good to me.
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.