Increased Stack Usage After Migrating to PSA Crypto (mbedTLS 4.x)

[Ashish285]

Summary

Hi all, after migrating from mbedTLS v3.6.5 to v4.0.0, we have observed a noticeable increase in stack usage during TLS operations. This appears to be related to the switch from the legacy mbedtls_* API to the PSA Crypto API, which uses larger operation structures.

I’d like to confirm whether this increase is expected.

System information

Mbed TLS version (number or commit id): 4.0.0
Operating system and version: ESP-IDF
Configuration (if not default, please attach mbedtls_config.h): default
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information: NA

Expected behavior

We were expecting little to no increase in the stack usage after the PSA migration.

Actual behavior

Running a TLS client example on an ESP32 shows an overall ~800-byte increase in stack usage during the TLS handshake after upgrading to mbedTLS 4.x. This difference is compared to the same example running with mbedTLS 3.6.5

Questions

• Is this stack usage increase expected as part of the PSA migration?
• Are there recommended options or configurations to reduce stack usage when using PSA Crypto?
• Are there plans to optimize PSA context sizes or allow storing them outside the stack?

Please let me know if any additional details are required or any tests needed to be run.

Thanks!

[gilles-peskine-arm]

We've changed the API between the cryptographic primitives and the X.509/TLS layers. A bunch of things are still optimized for the old API. For CPU time it probably doesn't make a difference because the time is happening in low-level crypto. For code size it's generally a win if you have crypto accelerators but a loss if you don't, although it can depend on the exact set of features, and there is now a mandatory keystore which has a cost and which we'd like to make optional but it's nontrivial. For RAM (both stack and heap), I'd generally expect some increase, highly variable depending on the configuration. I'm afraid we haven't made precise measurements.

Some of the cleanups that we're currently doing might save some RAM, although I think mostly heap and not stack. Our current roadmap has more plans for optimization in 2026, but so far it's focused on code size, not RAM usage.

I do think we need to do a stack audit. There are probably optimizations that we can do now that we no longer need to support two crypto APIs, but we haven't identified them yet.

With the code as it is now, for stack usage, the only easy thing I can think of is to disable RSA and FFDH, so that ECC is the only asymmetric cryptography. That will definitely reduce RAM usage, and I think some of that is on the stack.