Default RSA key bitlength should be 4096
kaystrobach opened this issue · comments
as your mayor idea is security take the maximum possible ... don't use scary defaults, make it secure by default and let users downgrade if they need to.
Thank you for all your efforts
4096 is silly. if you want bigger than 2048, the next logical step would be 3072 (~128-bit LoS), and 7168-bit (~192-bit LoS) after that.
but 2048-bit should be ok until about 2030, and by then everyone should be using something better like ECDSA or EdDSA, so there's no good reason to use larger RSA keys.
Well startssl offers 2048-bit and 4096-bit keys nothing in between and they are known to be working with most browsers.
Imho the keylength should be longer then 2048-bit ....
If you truly want to be secure, you should be generating your own CSR and private keys. (Not allowing StartSSL to generate them for you).
StartSSL will happily sign a 3072-bit CSR though they will not offer to generate one for you. I happen to have one. (https://jdkasten.com)
There are way larger problems with TLS deployment than the size of the RSA key. Poodle, FREAK LogJam to name a few in very recent memory.
The overarching goal is to increase the deployment of HTTPS (https://freedom-to-tinker.com/blog/jhalderm/announcing-lets-encrypt/). Part of the consideration should be speed while following the latest best practices as defined by the security research community. I don't believe I have seen any academic work suggesting the need to abandon 2048.
@hotaru2k3
I assume that when you say it will be okay until 2030, you are referencing this study by NIST. Personally, I don't trust it. People have the naive ability to assume technology has somehow "peaked", and will only continue at it's current rate. I will trust 2048 bit keys for half that time, if we're even still using RSA then.
I don't understand why "4096 is silly". For comparable strength in terms of bits of security, sure, 3072, 7680, and 15360 keys make sense, but that's like taking liters of water into a desert rather than the 2.5 you could have because it's a round number. 4096 bits is a common option at most certificate authorities that I've worked with, and all modern browsers seem to support them. Why not use the highest security commonly supported today?
I have always generated my own keys, and will continue to do so if this system allows it. While I'm sure there are many pointed problems aside from key size, the fact that their have been other issues do not mean key size does not, or will not, factor into the security of the system.
To use your examples, Poodle can be mitigated by disabling SSLv3 (something I had already done at the time), while Freak could be overcome by disabling export-type ciphers (along with some other, older, and less secure options). Finally, the Logjam Attack was directly related to cracking a key with a small length, although DH Parameters. This was the only attack I was not already armoured against, and required, you guessed it, generating longer keys.
While the overall goal is to deploy more HTTPS, I see little point in deploying below-maximum-standard HTTPS. If we can have larger keys that are supported, I see little reason not to use them. The only argument I have seen against it is speed, in which case we are likely discussing hundredths of a millisecond, and is not something I would like my systems to be held back by.
if you want to use "the highest security commonly supported today", that's 384-bit ECDSA. 4096-bit RSA isn't anywhere close to that. if 2048-bit RSA isn't strong enough, switching to ECDSA makes a lot more sense than using bigger RSA keys.
@lewisgoddard Really no need to discuss this further... but by your logic we should be using 8192 or 16384 bit keys (browser trusted certificates exist with these key sizes). I should note that you are free to generate whatever size key you would like.
I personally run a 3072 bit key, but believe it should be cryptographers along with security experts that should be making recommendations. Arguments should be made with scholarly work, not unjustified conjecture.
I don't believe the main issue with the performance is with the cryptographic operation, but rather the fact that you have to send over twice as much information over the network. (TCP slow start).
97% of the Internet runs on 2048 and there are some extremely valuable keys out there. Cracking 1024 is still considered requiring nation-state resources. (It would be extremely expensive).
The point of listing the attacks is that more time should be focused on configuration rather than key size. You may note that #374 was raised before LogJam was public, yet still has not been implemented/fixed. I should get back to working on that.
ok, lets close it for now, still believe longer keys are better 😄
@hotaru2k3
While I would certainly prefer to upgrade from RSA entirely, thanks to the systems I must support I myself are unable to. 4096 bit RSA doesn't have to reach that same standard, I just use it because it is superior to 2048 bit RSA.
Again, larger keys are more secure, and again, due to the user base I must support I am unable to go higher than 4096 bit. Where I able to I would begin to consider the applications of larger versus the time taken to decrypt messages with them, but in it's current state I find the difference negligible.
With every doubling of the RSA key length, decryption is 6-7 times times slower.
The following was generated on a 7 year old system with the command openssl speed rsa
Doing 1024 bit private rsa's for 10s: 24131 1024 bit private RSA's in 9.99s
Doing 1024 bit public rsa's for 10s: 417942 1024 bit public RSA's in 9.98s
Doing 2048 bit private rsa's for 10s: 3687 2048 bit private RSA's in 9.97s
Doing 2048 bit public rsa's for 10s: 107055 2048 bit public RSA's in 9.95s
Doing 4096 bit private rsa's for 10s: 450 4096 bit private RSA's in 9.87s
Doing 4096 bit public rsa's for 10s: 31805 4096 bit public RSA's in 9.99
To be clear, that's around 22 milliseconds for a private RSA at 4096 bit, versus 2-3 milliseconds for a 2048 bit key. I really cannot see any of my users complain about long handshake times when human reaction times are 10 times longer, especially with the rise of SPDY and HTTP2 allowing less connections for a handshake (I really don't think doubling the ~2Kb of key data is going to make much difference to the network, it's mostly connections).
As I said, the upper limits of many of my users are a 4096 bit RSA key, and so that is what I would prefer to use. Personally, I am complacent with any system that at least allows me the option to do so, and will likely continue to use the highest commonly available.
All modern browsers support 4096, why letsencrypt shouldn't. It's simply rational.
As extra step forward let user generate ECDSA 256 by default.
https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
For AES-128 equal strength we should use a >= 3072 bit RSA private key (15360 bit for AES-256).
The only way to get 100% scores across the board with this test:
https://www.ssllabs.com/ssltest/
is to use >=4096 RSA keys.
This is the reason given:
"With some suites, the size of the key is the only factor that determines the strength of the key exchange. However, some suites will use RSA for authentication and DH for the key exchange. In the latter case, the key strength is equal to the weaker of two. If you look at your results, you will find that some DH parameters are 1024 bits, which is what is bringing your score down."
[Retracted comment as I had missed the option to specify '--rsa-key-size 4096']
Still believe it should be the default though...
Let's Encrypt supports longer keys. 2048-bit is the default.
I think @lewisgoddard is making good arguments, and I've yet to see a counterpoint against longer keys that isn't “other things can go wrong” or “speed”.
Why is the default 2048-bit? Instead of asking “why larger”, shouldn't the question be “why not larger”?
Untested? I guess there might be issues with longer keys that haven't been discovered yet, and using something too out of the ordinary probably isn't desirable.
I'd like the default to be as long as can be assumed not to be a problem with people's implementations and user clients. Is that 2048-bit RSA or could we push it to 3072-bit or 4096-bit and let those with specific requirements lower it? Perhaps explain that if you serve a relatively high amount of traffic, the longer default might be an issue.
I understand you have limited amount of work hours to determine every detail perfectly, and in either case this default can be changed later.
@lewisgoddard Really no need to discuss this further... but by your logic we should be using 8192 or 16384 bit keys (browser trusted certificates exist with these key sizes). I should note that you are free to generate whatever size key you would like.
I find this statement ridiculous. Key lengths beyond 4096-bit RSA currently don't seem well-supported. How supported are alternatives to RSA (ECDSA etc.)?
I personally run a 3072 bit key, but believe it should be cryptographers along with security experts that should be making recommendations. Arguments should be made with scholarly work, not unjustified conjecture.
Where are these experts, who should we trust, and are they producing publications we could be reading? I don't expect you to know all the answers, but it's a question I want to raise for everyone.
Cheers, and thanks for Let's Encrypt!
Most users don't change defaults. The default should thus be the best compromise between security and usability.
Comments above highlight that 4096-bit is the upper bound for usability.
The ssllabs tests show that 4096-bits is the lower bound for security.
Why not use 4096 as a default?
The ssllabs tests show that 4096-bits is the lower bound for security.
Wrong. Show me where anyone at "ssllabs" (AKA Qualys) says that >=4096 is required for security. If you want to waste 8x the cpu cycles per connection, you have the option to (see above graph someone else posted). No need to make it default. 2048 is widely the agreed upon as the industry standard at this current time.
Almost always when people use 4096-bit RSA they’re doing so because they believe RSA-4096 to be much stronger than it is. The United States’ National Institute of Standards and Technology (NIST) states that RSA-2048 gives roughly 112 bits of security and RSA-3072 gives roughly 128. There is no formal recommendation on where RSA-4096 lies, but the general consensus is that it would come in somewhere around 140 bits — 28 bits of improvement over RSA-2048. This is an improvement so marginal that it’s really not worth mentioning.
[...]
RSA-4096 is not a bad idea: it’s just, generally speaking, unnecessary. You gain very little in the way of additional resistance to brute-forcing and cryptanalysis.
— https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096
Many of you assume that there are no shortcuts in solving ECDSA (inherant weakness in using an elliptic curve) and compare it to RSA based on that assumption.
RSA should always be an option.
RSA keys with >2048 bits are currently incompatible with Amazon Web Services. From the Amazon CloudFront Developer Guide:
The maximum size of the public key in an SSL/TLS certificate is 2048 bits
Just thought I'd add this extra point into the conversation.
Note that the letsencrypt client also change the private key at least every 90 days when renewing certificate. If you use perfect forward secrecy, this means that an attacker as 90 days to crack to a private key (to do a MITM attack) before it becomes useless (tanks to PFS an attacker cannot find the session symmetric secret key afterwards).
The US Gov is starting to recommend 3072. So there are now starting to get standards/recommendations for things longer than 2048.
https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
(Excuse the DoD CA which browsers don't trust)
@nitmir Except that barely anyone is changing their private key every 90 days as well, so the brute forcing on the grabbed captures can just continue on where it left off..
@jult I am fairly certain that Certbot does that automatically, which was their point.
Ah, I was not even aware of that. Thought they'd do that only once, the first time, on each server. Apparently not indeed. Different for the Diffie-Hellman keys though, but they take looong to be generated for 4096, so that's to be expected.
Yes, they are. To bypass currently, you have to use the manual plugin. An option is on the way for reusing a key though, but that won’t be the default.
Agree. 4096 length should be the default rsa-key-size.
Everyone says: You cannot crack a 2048 bit key today.
But what is if you have information that still has to be secret in 20 Years? That's the important thing. It's not about today, data can be saved and cracked later. While this is not critical for most data it's critical for some data and there's the problem.
People who were interested in this issue, please see #2080 where I discuss various issues about recommendations and security models with other people (including the long-term secrecy issue that @cromefire brought up here). Hopefully this will address some of your questions and interests about the keylength defaults.