The PSA key store is too small for high-end platforms

[gilles-peskine-arm]

For high-end platforms such as Linux, the default size of the PSA key store is too small (32 entries).

This has a much bigger impact since Mbed TLS 3.6.0, which uses PSA for TLS 1.3 connections. So I'm filing this issue as a regression to solve in 3.6.1. If we end up not enabling TLS 1.3 by default at runtime in 3.6.1 for other reasons (needing psa_crypto_init, mandating server authentication, …) then this issue is less important.

For example, curl thinks 50 connections is reasonable, and I agree. 32 is too small in the default configuration.

High-end platforms really need a variable-size keystore. Unfortunately that's annoying to implement without realloc.

As of Mbed TLS 3.6.0, each key slot uses 56 bytes on a 64-bit platform, 40 bytes on a 32-bit platform.

[gilles-peskine-arm]

By the way, the documentation of MBEDTLS_PSA_KEY_SLOT_COUNT is misleading:

Restrict the PSA library to supporting a maximum amount of simultaneously loaded keys.

Actually, the key store has a fixed size, and this is the size. Unlike what the current wording implies, there is currently no way to have an unrestricted key store size.

[bagder]

curl not only thinks 50 connections is "reasonable". It has no specific upper limit in the number of parallel connections it can do (in a single thread), both in a command line tool use or by using the libcurl API directly. There are curl users using (tens of) thousands of parallel connections.

[gilles-peskine-arm]

My proposal for 3.6.1: add a new compile-time boolean option MBEDTLS_PSA_KEY_SLOT_DYNAMIC, which the default config file defines. If undefined (as will be the case for users who have their own config file), you get the current behavior and code size. If defined, the key store will grow dynamically, so keys will effectively unlimited, at the cost of a little increase in code size and RAM usage (unacceptable for highly constrained platforms, but negligible for high-end platforms such as anything running Linux).

Given the time frame, I propose to do something that works for a large number of keys, but does not attempt to be efficient for a very large number of keys: there will be behavior that's linear in the number of keys. Performance should be acceptable for 1000 keys, not for 10000000 keys. We can revise this in 3.6.2 if there's a need.