Hello,
Mbed TLS is currently transitioning from its classic cryptography API (mbedtls_pk_xxx, mbedtls_rsa_xxx, etc.) to a new API (psa_xxx, https://armmbed.github.io/mbed-crypto/html/ https://armmbed.github.io/mbed-crypto/html/). A major difference is that the new API is a lot more opaque, which makes it easier to swap crypto implementations and algorithms under the hood. An application using the PSA crypto API should need very little change to use a different signature algorithm and moving the implementation of the crypto primitives to a TEE/SE should be fully transparent.
For a TEE, the idea is to run the crypto-and-keystore library as a TEE service.� We are working on implementing a driver mechanism (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver... https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver-interface.md, https://github.com/orgs/ARMmbed/projects/18#column-15836331 https://github.com/orgs/ARMmbed/projects/18#column-15836331 �Driver interface: API design and prototype� and more) that allows plugging in accelerator drivers (using keys in cleartext) and secure element drivers (where the crypto library only has a handle to the key, or a wrapped copy of the key, and the driver contacts the SE to perform the operation). The parts that are already implemented are being used in production, but a lot of features are still missing.
The PSA crypto API is not ready for PQC. It makes some assumptions (public keys are small, signatures are small, keys have no state, ...) that make sense for classic asymmetric crypto but not for PQC. We intend for version 2 of this API to have modifications for PQC, but I have no idea when this will happen.
One of the changes we're making in the move to PSA crypto is that the mbedtls_pk_ API is becoming a wrapper around psa_xxx calls. A limitation of the PSA API is that it doesn't have any form of key parsing (e.g. PKCS#8, X.509). In the long term, the pk module may stay on as a key parsing and formatting layer, or that may become a new psa API, we haven't decided yet. We also don't know if pk would be extended to cover new algorithms.
The X.509 and TLS code have to care a lot about specific public-key algorithms, and to a lesser extent about specific cipher algorithms, due to the history of the protocols. TLS 1.3 has made the story a lot simpler, but for older versions, the TLS code needs to know how to negotiate supported groups and point formats, to combine CBC and HMAC when not using AEAD, etc. We are currently switching the X.509 and TLS code to use the PSA crypto API, often across mbedtls_cipher and mbedtls_pk compatibility layers (https://github.com/orgs/ARMmbed/projects/18#column-15836318 https://github.com/orgs/ARMmbed/projects/18#column-15836318 �Use PSA Crypto more - part 1� and more), but this won't help to reduce all the algorithm-specific code that has to be there due to the protocol design.
We would be happy to collaborate on adding support for hybrid cryptography. However, at the moment, we are prioritizing other topics: (D)TLS 1.3, full transition to the PSA API, full support for accelerator drivers and secure elements...
Best regards,