Hi all,
From the announcement and also the long term plans (https://mbed-tls.readthedocs.io/en/latest/project/long-term-plans/) it is apparent that bignum/ecp operations on the public API will go away and usage will be restricted to internal only.
I do understand and welcome the shift towards PSA API and to abandon the ALT interface for higher level legacy API crypto functions. However, I'm not so positive about removal of the bignum and ecp API. There are projects using those functions even in their PSA porting layer (Matter comes to mind: https://github.com/project-chip/connectedhomeip/blob/master/src/crypto/CHIPC...) or projects using the bignum layer as abstraction (Zephyr hostap/wpa_supplicant: https://github.com/zephyrproject-rtos/hostap/tree/main/src/crypto, crypto_mbedtls*.c).
There might be a case to support those functions to have (hardware-accelerated) low level building blocks for algorithms Mbed TLS doesn't yet or never will support. As other SSL libraries such as OpenSSL also expose similar API (BN_ and EC_POINT_ ), the removal in Mbed TLS will certainly leave a gap.
What's the view here from the project team?
Cheers,
Gernot
Hi Gernot,
From a product management perspective, we don't want to expose low-level cryptography APIs to applications because they are not present on platforms where the corresponding algorithm is not fully implemented in software, or where the cryptography happens in a separate service.
From a product maintenance perspective, we don't want to expose low-level cryptography APIs because we want the freedom to change them. In the past, preserving those APIs has made some optimizations more complicated or impossible, and has made some security improvements more complicated or inefficient.
Obviously bignum and ECP arithmetic will remain in the project, and if you really want to call those functions, you can. But we don't guarantee any stability. We won't even provide advance warning for changes since we may change those internal interfaces in a security fix.
With respect to Matter: we're going to implement SPAKE2+ in Mbed TLS, though it probably won't be ready by the time of the 4.0 release.
With respect to hostap in Zephyr: why is it exposing low-level interfaces? If you really want arithmetic APIs then you can still use Mbed TLS but we won't provide a stable API any longer, and it is incompatible with hardware acceleration and service separation.
Best regards,
mbed-tls@lists.trustedfirmware.org
-
Gernot Kvas -
Gilles Peskine