Private key size > 4096 - strange error message

Hi,
does letsencrypt.org server has any restrictions for private key size?

One of letsencrypt_plugin users has a problem with key size = 8192. I can reproduce this error with a private key generated in following way: openssl genrsa 8192 > key/keyfile.pem sever responds with an error: “Acme::Client::Error::Unauthorized: No registration exists matching provided key”. Is it correct behavior?

1 Like

Yes there is an restriction to 4096 you can find the restrictions in


Line 74
Minimum size is 2048 and Maximum Size is 4096 and also some quality checks on the key.

Does anyone know why Let’s Encrypt has such upper limits to the RSA key size?

The CA/Browser Forum only mentions minimum key sizes in its Baseline Requirements.

Performance perhaps? Signing a bigger key puts a heavier burden on the signing process?

Hi, signing bigger keys is no performance issue. Because for signing you first calculate the SHA256 hash and
the sign it with the CA Private RSA key.
The heavier burden is when you use the large RSA key for key exchange/signing in tls as server.
I think it is the same as the limit to only two EC curves the *** argument that it is not widely supported.

2 Likes

Thanks for information! :slight_smile:

Well, the modulus of a large RSA key is a vey big part of the certificate, right? And you can’t deny that calculating the SHA256 hash of a bigger piece of data costs more CPU power than a smaller piece of data, right? :wink:

But you’re right, that probably won’t be a very big performance penalty indeed. :slightly_smiling: Your argument is more likely I’m afraid.

[offtopic] Did you know in elliptic curve ciphers, the verification part is relatively heavy performance-wise compared to signing? In the end EC ciphers are still a better choice compared to RSA, but for a client a RSA key is easy peasy while a large EC curve verification is relative heavy.

  1. SHA256 is done as you said in the CPU in this case it is the server cpu. This mean it can be delegated to multiple server. But the “expensive” part is the signing of the hash done by HSM module.
  2. Large key require more space in the CT servers and for OCSP and is expensive on mobile devices.
  3. ECDSA the signing is in the prime field is depending on the optimisation maximum about twice as fast as verification.
2 Likes

Performance and size.

3 Likes