Consider removing support for small RSA keys #111

New issue

Open

opened 2024-09-02 07:28:30 -05:00 by gilles-peskine-arm · 0 comments

gilles-peskine-arm commented

2024-09-02 07:28:30 -05:00

(Migrated from github.com)

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.

There is now a movement to stop supporting smaller RSA keys — see [Hacking a Virtual Power Plant](https://rya.nc/vpp-hack.html), [OpenSSL issue](https://github.com/openssl/openssl/issues/25092), [Go issue](https://github.com/golang/go/issues/68762). 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](https://en.wikipedia.org/wiki/Integer_factorization_records) is [829 bits](https://listserv.nodak.edu/cgi-bin/wa.exe?A2=NMBRTHRY;dc42ccd1.2002) (taking roughly 2700 core-years). [Since Mbed TLS 3.5.0](https://github.com/Mbed-TLS/mbedtls/pull/7864), we [prevent the generation of RSA keys smaller than 1024 bits](https://github.com/Mbed-TLS/mbedtls/issues/7556). 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.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#111

No description provided.

Rows
Columns