Consider removing support for small RSA keys

[gilles-peskine-arm]

There is now a movement to stop supporting smaller RSA keys — see Hacking a Virtual Power Plant, OpenSSL issue, Go issue.

Data points: 512-bit RSA has been trivially broken for more than a decade. 1024-bit RSA still holds safe to academic research. The latest public factoring record is 829 bits (taking roughly 2700 core-years).

Since Mbed TLS 3.5.0, we prevent the generation of RSA keys smaller than 1024 bits. The initial motivation was to block users from unwittingly requesting a 128-byte or 256-byte key, but getting a 128-bit or 256-bit key. It also prevented the use of a bit-size that is sensible for symmetric keys or for ECC but not for RSA. The minimum size is a compile-time option (MBEDTLS_RSA_GEN_KEY_MIN_BITS). Since generating such small RSA keys is not sensible, we considered this change acceptable for a minor release. We did not change our long-time support branch (but it was a close call).

The goal of this issue is to decide whether we want change our RSA limits in Mbed TLS 4.0 and TF-PSA-Crypto 1.0, and if decided, implement this decision.

• Should we change the default value of MBEDTLS_RSA_GEN_KEY_MIN_BITS to 2048?
• Should we start enforcing a minimum RSA key size when importing keys? If so what should be the limit?
• Should we start enforcing a minimum RSA key size per operation? (Note that this is at the crypto level — X.509 and TLS in Mbed TLS have their own policies.)

Added to the 4.0 planning board since this is potentially a feature removal that we would not want to do in a minor release.