crypto/rsa: refuse to generate and/or use keys smaller than 1024 bits

[FiloSottile]

crypto/rsa is unusual in that it can be secure (used with a key size > 2048) or completely insecure (used with a key size such as 512 bits, which can be broken on a laptop). Small keys are sometimes useful in tests, but having an rsa.PrivateKey value that behaves and looks exactly like a secure one but actually provides no security at all is a significant footgun.

In production, if a 512-bit key is used, it's overwhelmingly likely that the operator thinks they have security and doesn't (this happens in the real world on a regular basis) as opposed to being intentional about using fake RSA, so this feels like one of those rare occasions where breaking them is justified.

I propose we do both the following in Go 1.24:

1. return an error from rsa.GenerateKey if bits is less than 1024
2. return an error from all Sign, Verify, Encrypt, and Decrypt methods if the key is smaller than 1024 bits

GODEBUG=rsa1024min=0 reverts to the old behavior.

OpenSSL sounds on the way to doing (1) in a minor release and (2) in a major release. openssl/openssl#25092

To avoid slow key generation in tests, we can recommend using the test keys in RFC 9500. If anyone has a good idea for how to expose them, we can even provide them ready to use.

We could also disable the restriction based on testing.Testing() but I would keep that as a fallback if the amount of tests that require fixing turns out to be truly unmanageable, because generally tests are supposed to test actual behavior.

[alex]

For pyca/cryptography (most widely used Python cryptography library) in our last release (~3 weeks ago) we enforce a minimum of 1024-bit for RSA key generation (up from 512-bits in the previous release).

This has produced only one complaint, about a testing workload (where small keys were being used for performance).

We're also interested in enforcing key sizes in signing/verification (or perhaps in key loading), but haven't done so yet.

[FiloSottile]

To avoid slow key generation in tests, we can recommend using the test keys in RFC 9500. If anyone has a good idea for how to expose them, we can even provide them ready to use.

An easy answer to this is a GenerateKey or package-level example, for folks to copy-paste.

We could also disable the restriction based on testing.Testing() but I would keep that as a fallback if the amount of tests that require fixing turns out to be truly unmanageable, because generally tests are supposed to test actual behavior.

Actually, this is not a good idea. Packages can opt in to the equivalent behavior simply by doing

func init() {
    os.Setenv("GODEBUG", os.Getenv("GODEBUG") + ",rsa1024min=0")
}

in a test file (or an equivalent, test-scoped operation).

[ericlagergren]

We could also disable the restriction based on testing.Testing()

This also requires crypto/rsa to import testing, which isn't good.

[rittneje]

@FiloSottile Are you committing to supporting that GODEBUG forever? There are legitimate reasons to use smaller keys, and we shouldn't have to fork the Go standard library to work with them.

Also, I really don't think this should (only) be a GODEBUG. When smaller keys are intentional, it is going to be for some specific use case. Having this toggle for the entire application is too coarse grain. It would be far preferable to be able to opt-in per function/method call.

[mcpherrinm]

Do you have an examples of those legitimate use-cases? I admit they may exist but besides test-case reasons, I am not aware of why you’d want to use RSA < 1024. Even 1024 is a stretch these days for anything that requires actual security. I almost want 1024 gated behind a GODEBUG too

[rittneje]

@mcpherrinm We have some edge devices that can only hardware accelerate 256-bit. I thought they were RSA, but turns out they are elliptic (P-256), so we're good!

[mcpherrinm]

Great: P-256 elliptic curves have strength greater than RSA-2048 and are well within the margin of safety today.

Confusion about key strength for different algorithms is one of the common reasons for accidental use of RSA-512. For example, hashicorp/consul#20112 defaulted to a key size of 256, which was suitable for P-256 but totally inappropriate if Consul was configured to use RSA but didn’t have a key size set.

This proposal would have prevented that issue.

[FiloSottile]

A recent example of a real world security incident due to production usage of RSA 512-bit keys. https://rya.nc/vpp-hack.html (This incident prompted this proposal, but it was not public at the time.)