PSA Crypto API results in larger binary size compared to direct mbedTLS API - seeking guidance on optimization

[Ashish285]

Summary

We've been evaluating the PSA Crypto API as a migration path from direct mbedTLS calls and noticed that for basic SHA-256 hashing, the PSA implementation produces approximately 17KB additional flash usage. We'd appreciate guidance on whether this is expected behavior and if there are optimization strategies we might be missing

System information

Mbed TLS version (number or commit id): 3.6.3
Operating system and version: ESP-IDF v5.5
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:

Expected behavior

We expect to see similar flash usage with the PSA APIs as the direct mbedTLS APIs.

Actual behavior

Size Analysis Results
Total flash size difference: +17,104 bytes
Text section difference: +15,960 bytes
Rodata section difference: +1,144 bytes

Current approach:

• Using identical mbedTLS configuration macros for both builds
• MBEDTLS_PSA_CRYPTO_CONFIG is not enabled (using default behavior)
• Relying on automatic PSA symbol deduction from MBEDTLS_* symbols

Observations from symbol analysis:

The PSA build appears to include additional algorithms beyond SHA-256:

• mbedtls_sha512_software_process: +3,216 bytes
• esp_internal_sha1_parallel_engine_pr: +4,516 bytes
• Various SHA-1, MD5, and SHA-512 related functions: ~600+ bytes total
• Additional infrastructure: entropy/DRBG, key management, error translation (~2KB+)

Comparison with direct mbedTLS:

When using direct mbedTLS calls, the linker effectively performs dead code elimination. Even with multiple hash algorithms enabled in the configuration, only the functions actually used (SHA-256) appear in the final binary.

Questions

We're hoping you could help us understand:

• Expected behavior: Is this size difference typical when migrating from direct mbedTLS to PSA API? We'd appreciate understanding if this represents the expected cost of PSA's standardized interface.

• Configuration guidance: We noticed the documentation mentions PSA_WANT_ALG_* macros for fine-grained algorithm selection. Would you recommend:

  • Enabling MBEDTLS_PSA_CRYPTO_CONFIG and explicitly configuring PSA_WANT_ALG_SHA_256?
  • Is this the recommended approach for size-conscious applications?

• Dead code elimination: Is there a way to achieve similar dead code elimination with PSA as we see with direct mbedTLS calls? Or does PSA's abstraction layer inherently prevent this?

• Migration best practices: For applications migrating from direct mbedTLS to PSA, what would you recommend as the optimal configuration strategy to minimize size impact?

Steps to reproduce

Build a binary with the following code and check the binary size difference.

PSA Implementation:

psa_crypto_init();
psa_hash_operation_t hash_op = psa_hash_operation_init();
psa_hash_setup(&hash_op, PSA_ALG_SHA_256);
psa_hash_update(&hash_op, data, len);
psa_hash_finish(&hash_op, hash, sizeof(hash), &hash_length);

Direct mbedTLS Implementation:

mbedtls_sha256_context ctx;
mbedtls_sha256_init(&ctx);
mbedtls_sha256_starts(&ctx, 0);
mbedtls_sha256_update(&ctx, data, len);
mbedtls_sha256_finish(&ctx, hash);
mbedtls_sha256_free(&ctx);

Additional information

[davidhorstmann-arm]

Hi, thanks for this report!

In answer to your questions:

• We expect there to be some size increase with PSA crypto because it's currently implemented as a wrapper around the Mbed TLS legacy APIs. We're hoping to optimise most of this away in future versions. However, 17KB seems a bit steep, I wouldn't expect as big an increase as that.
• Configuration: You are right about the correct approach - enable MBEDTLS_PSA_CRYPTO_CONFIG and only enable PSA_WANT_ALG_SHA_256 (i.e. disable all other PSA_WANT_ALG_ options. Hopefully this should yield a lesser code size increase than before
• Dead code elimination: The PSA API seems to make things more difficult for link-time optimization, anecdotally. This means that it's more important to explicitly turn off features you are not using (by disabling the relevant PSA_WANT_ALG_ options). This should allow you to get to a comparable code size as with LTO.
• I'm unsure if the configuration type (legacy or crypto) has much impact on the code size, but I expect using PSA crypto config to be better when using the PSA API, as there is some imprecision in how we adjust configs. However the legacy options will be going away in future versions of Mbed TLS / TF-PSA-Crypto, so it's better for future-proofing to use the PSA configuration options anyway.

I hope that helps.

[gilles-peskine-arm]

Currently, all builds using PSA Crypto include a random generator and a key store. Many configurations needs those anyway, but if you only use hashes, it's a massive overhead.

I'm not sure how much of that link-time optimization can remove.

Unofficially, you can call hash functions without having called psa_crypto_init(). In practice, psa_crypto_init() is needed for three things:

• For the RNG — not needed for hashes.
• For the keystore — not needed if you don't use any keys.
• To initialize any accelerator drivers. If you have a hash driver and it requires initialization, call its initialization manually instead of psa_crypto_init().

We have a prototype for making partial initialization an official feature of both TF-PSA-Crypto (formerly part of Mbed TLS) and the standard PSA API, but it isn't merged yet. Hopefully in 2026.

[Ashish285]

Thanks for the detailed guidance! After applying the recommended configuration changes, including removing psa_crypto_init() and adjusting the PSA_WANT_* macros, I was able to reduce the size overhead to under 5 KB. I think I can look more into it and try to optimise even more but this confirms that PSA Crypto requires explicit fine-tuning of the PSA_WANT_* macros to achieve optimized binary size.
In contrast, applications using direct mbedTLS APIs often benefit from the toolchain’s automatic dead code elimination.

This has an important implication: migrating from mbedTLS to PSA APIs shifts the optimization responsibility from relying on broad feature inclusion and linker stripping to explicitly selecting only the needed algorithms for minimal footprint.

Support for partial initialization would also be highly beneficial to enable only the required PSA functions at runtime.