ECP keypair utility functions

[gilles-peskine-arm]

Add utility functions to the ECP module to query and construct key pairs and points. This replaces the direct access to mbedtls_ecp_keypair and mbedtls_ecp_point fields that was possible in Mbed TLS 2.x. Fixes #5441, fixes #8367, fixes #8652.

Update the sample programs. They now no longer do any direct access to private fields of mbedtls_ecp_keypair or mbedtls_ecp_point. Fixes #5017. Note that any unrelated improvement of sample programs or their testing is out of scope here. I used the following to test them:

• run programs/pkey/ecdsa
• run smoke.sh secp256r1 && smoke.sh x25519 using smoke.sh.txt

Follow-up: use the new functions to simplify the PSA transition guide.

PR checklist

Please tick as appropriate and edit the reasons (e.g.: "backport: not needed because this is a new feature")

• changelog provided
• backport no (new feature)
• tests provided

[tom-cosgrove-arm]

This increases code size by 200 bytes when compiled for TF-M (their config, P-256 only, no programs/ used) with ArmClang 6.19 with -Oz

orig:5647d06be	pr:7815:1c8f9d61d	Delta	Filename
6464, 0	6664, 0	+200+0	ecp.o

[mpg]

Only a design review for now. I'm mostly happy except for export_coordinates() where I disagree with the current API and am not convinced we really need it at all (but not opposed to adding it either).

[gilles-peskine-arm]

I've pushed a new history that never creates mbedtls_ecp_point_export_coordinates. The actual development history, with that function added and removed and with some commits to fix minor issues based on CI or review feedback, but rebased midway on top of a recent development to avoid merge conflicts, is in https://github.com/gilles-peskine-arm/mbedtls/tree/ecp-export-partial-4.

[mpg]

Looking pretty good, just a few minor things and a couple of questions.

[mpg]

Looking good, apart from the superfluous BIGNUM_C guards that I'd like removed.

[mpg]

I'm removing "needs-design-approval" as I think we know have an agreement on the design.

[mpg]

LGTM

[minosgalanakis]

Looks good overall.

Two notes:

• I assume that the setter for public key mbedtls_ecp_read_public_key is intentionally missing?

  If a user needs to importa public key they should import the private one using mbedtls_ecp_read_key () and then calculate the public using mbedtls_ecp_keypair_calc_public() ?

• The show_ecp_key(const mbedtls_ecp_keypair *ecp, int has_private) method could be either a helper function for programs or even an API call? Given the complexity to produce a readable printout, we should at least point the users to how to do it.

The latter is not a strong ask, and should not block this PR.

[gilles-peskine-arm]

I assume that the setter for public key mbedtls_ecp_read_public_key is intentionally missing?

I'm not sure what that would be. How would it differ from mbedtls_ecp_set_public_key?

The show_ecp_key(const mbedtls_ecp_keypair *ecp, int has_private) method could be either a helper function for programs

It could be, but those programs are currently self-contained. They're sample programs, so there's a strong argument that people should be able to just take the one .c file and modify it. That's a high barrier for introducing a new dependency. Conversely, this is code that we rarely modify, so the cost of duplication is low. So this is a rare case where I think code duplication is ok, even if we didn't have time constraints.

or even an API call? Given the complexity to produce a readable printout, we should at least point the users to how to do it.

Printing out keys in a readable format is rarely done apart from demos. So it doesn't belong in the API, and I don't think we need to call it out in documentation.

[minosgalanakis]

LGTM