Hello,

We do plan to fully migrate to PSA APIs for cryptography. This means we'll retire mbedtls_md and mbedtls_cipher. The status of mbedtls_pk is still a little unclear because it does key parsing/writing, which PSA doesn't do; it might move to the x509 library since the supported key formats are mostly those used in X.509, or we may expand the PSA API to have similar functions.

It's highly likely that mbedtls_md and mbedtls_cipher won't be in Mbed TLS 5.0. It's not completely clear to me whether they'll be in Mbed TLS 4.0: they might be still available as a deprecated compatibility layer, depending on how much user demand there is.

Low-level crypto APIs (aes.h, ecp.h, …) will definitely not be in the public API of Mbed TLS 4.0, and ALT interfaces will no longer be supported.

Best regards,

Hi,

Let me complement what Gilles said (which fully matches my understanding) with a bit more about the TLS side. (TL;DR: nothing's decided yet.)

If I'm not forgetting anything, there are two kinds of TLS APIs that manipulate keys: those for asymmetric keys (private key associated to a certificate), and those for symmetric keys (PSK ciphersuites). Currently asymmetric keys are represented as a mbedtls_pk_context​ and you can warp a PSA key identifier in a PK context using mbedtls_pk_setup_opaque()​ in order to use it with the existing TLS API. For symmetric keys however, the existing API `mbedtls_ssl_conf_psk()` takes an array of bytes, so we created a new API mbedtls_ssl_conf_psk_opaque()​ that takes a PSA key ID.

What will happen to TLS APIs for asymmetric keys probably depends on the future of the PK layer, which as Gilles said is unclear at the moment.

Regarding TLS APIs for symmetric keys, my personal opinion is that we can keep both APIs (array of bytes and key ID) at least for 4.0 in order to ease the transition, perhaps with the "array of bytes" API deprecated in 4.0 and to be removed in 5.0. But that's just what I'm thinking at the moment, it may evolve and definitely does not represent any kind of team consensus.

Of course, if you have any input about what would be useful in order to make the transition easier on users, please let us know!

Best regards, Manuel.

________________________________ From: Gilles Peskine via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: 28 September 2022 21:21 To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Re: Mbed TLS4.0 - Remove legacy cipher APIs​

Hello,

We do plan to fully migrate to PSA APIs for cryptography. This means we'll retire mbedtls_md and mbedtls_cipher. The status of mbedtls_pk is still a little unclear because it does key parsing/writing, which PSA doesn't do; it might move to the x509 library since the supported key formats are mostly those used in X.509, or we may expand the PSA API to have similar functions.

It's highly likely that mbedtls_md and mbedtls_cipher won't be in Mbed TLS 5.0. It's not completely clear to me whether they'll be in Mbed TLS 4.0: they might be still available as a deprecated compatibility layer, depending on how much user demand there is.

Low-level crypto APIs (aes.h, ecp.h, …) will definitely not be in the public API of Mbed TLS 4.0, and ALT interfaces will no longer be supported.

Best regards,

-- Gilles Peskine Mbed TLS developer

On 28/09/2022 00:05, S Krishnan, Archanaa via mbed-tls wrote:

Hi,

In mbedTLS road map, there is a future task to remove legacy cipher API (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Does that mean all existing mbedtls crypto APIs will not be supported anymore?

mbedTLS is used for both its TLS and crypto library. I am curious how the planned changes will affect both set of users.

• Are the crypto library users expected to only use PSA crypto APIs and key IDs?
• Are the TLS library users expected to see API changes to TLS functions to support key IDs?

Thank, Archanaa

-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org