Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design how to access the fields of mbedtls_ecdh_context #5016

Closed
gabor-mezei-arm opened this issue Oct 5, 2021 · 3 comments · Fixed by #8863
Closed

Design how to access the fields of mbedtls_ecdh_context #5016

gabor-mezei-arm opened this issue Oct 5, 2021 · 3 comments · Fixed by #8863
Labels
component-crypto Crypto primitives and low-level interfaces enhancement needs-design-approval size-m Estimated task size: medium (~1w)

Comments

@gabor-mezei-arm
Copy link
Contributor

This is a design task, as part of #4683, to solve the private field access of mbedtls_ecdh_context by MBEDTLS_PRIVATE macro in programs.

The APIs in ecdh.h seems inconsistent, the lower level ones (mbedtls_ecdh_gen_public, mbedtls_ecdh_compute_shared) uses the mbedtls_ecp_group and the higher level ones uses the mbedtls_ecdh_context. This also cause private field access to gather the mbedtls_ecp_group from the mbedtls_ecdh_context.

Possible option to solve the private access:

  1. Make the private fields public
    • good for inner structures
    • locks the representation of the built-in typed data
  2. Create getter and setter APIs for field access
    • locks the representation of the built-in typed data
    • requires more memory and more CPU time
  3. Some mixture of the previous two option. Some fields are public, some are using getter and setter APIs
@gilles-peskine-arm
Copy link
Contributor

ECDH has a complex interface for two reasons. One reason is that there are really two interfaces: the “classic” interface (gen_public, compute_shared, …) and the TLS-oriented interface which is similar to the DHM module (make_params, make_public, …). Another reason is that under the hood, there are two very different implementations, which use different context structures: the Everest implementation (Curve25519 only, very fast but large code size) and the generic Mbed TLS implementation. Furthermore the context structure is currently in a state of flux between the “legacy” context (needed for the generic code in restartable mode, usable by the generic code in normal mode) and the “new” context (needed for Everest, usable by the generic code in normal mode). So I think in this case we'll need to stick to functions, which are tricky due to the need to balance performance with clear pointer lifetimes. We may need to add new functions that aren't just simple getters/setters.

@xlanor
Copy link

xlanor commented Nov 14, 2024

So I understand that this status is closed, but I'm looking for a little guidance here.

I'm backporting some old code that reads a private key from binary and reconstructs the public key.

That used to be possible, but doesn't appear possible anymore.

How should one approach this?

@gilles-peskine-arm
Copy link
Contributor

@xlanor Could you clarify what you're trying to do? There are functions to manipulate private keys and public keys in ecp.h, in particular mbedtls_ecp_write_key_ext(), mbedtls_ecp_write_public_key() and mbedtls_ecp_read_key().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component-crypto Crypto primitives and low-level interfaces enhancement needs-design-approval size-m Estimated task size: medium (~1w)
Projects
Status: [3.6] Mbed TLS PRIVATE
Development

Successfully merging a pull request may close this issue.

5 participants