I was wondering about the state of crypto APIs in Zephyr and whether it makes sense to move them forward or instead we should consider simply using the mbed TLS set of APIs as Zephyr's crypto API.
The reason I say this is that today we have include/crypto/cipher.h which abstracts ciphers, but that's about it. Most users in the code seem to use mbed TLS APIs directly when they require crypto functionality (with the exception of Bluetooth which can use TinyCrypt or mbed TLS and has its own abstraction) with only the IEEE 802.15.4 stack using cipher.h.
mbed TLS is a recognized crypto API that (as far as I know) can be used with or without the actual mbed TLS implementation, so I question the need to define our own in this particular case, although I might be missing key information. Unless I am mistaken one can implement hardware-accelerated or custom or proprietary implementations of crypto functions and shim them so that they expose the mbed TLS API.
In any case I do believe this is something that needs discussion since the current usage in the tree is inconsistent and the subset of APIs defined in include/crypto is very small.
If we did decide to use mbed TLS as an API we would then also need to discuss how to go about it, since mbed TLS is today an (optional) module and therefore the header files themselves are not included in the main zephyr tree.