New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default RSA key bitlength should be 4096 #489

Closed
kaystrobach opened this Issue Jun 11, 2015 · 27 comments

Comments

Projects
None yet
@kaystrobach

kaystrobach commented Jun 11, 2015

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

@hotaru2k3

This comment has been minimized.

Show comment
Hide comment
@hotaru2k3

hotaru2k3 Jun 20, 2015

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.

hotaru2k3 commented Jun 20, 2015

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.

@kaystrobach

This comment has been minimized.

Show comment
Hide comment
@kaystrobach

kaystrobach Jun 20, 2015

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 ....

kaystrobach commented Jun 20, 2015

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 ....

@jdkasten

This comment has been minimized.

Show comment
Hide comment
@jdkasten

jdkasten Jun 20, 2015

Contributor

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.

Contributor

jdkasten commented Jun 20, 2015

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.

@lewisgoddard

This comment has been minimized.

Show comment
Hide comment
@lewisgoddard

lewisgoddard Jun 21, 2015

@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?

lewisgoddard commented Jun 21, 2015

@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?

@lewisgoddard

This comment has been minimized.

Show comment
Hide comment
@lewisgoddard

lewisgoddard Jun 21, 2015

@jdkasten

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.

lewisgoddard commented Jun 21, 2015

@jdkasten

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.

@hotaru2k3

This comment has been minimized.

Show comment
Hide comment
@hotaru2k3

hotaru2k3 Jun 21, 2015

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.

hotaru2k3 commented Jun 21, 2015

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.

@jdkasten

This comment has been minimized.

Show comment
Hide comment
@jdkasten

jdkasten Jun 21, 2015

Contributor

@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.

Contributor

jdkasten commented Jun 21, 2015

@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.

@kaystrobach

This comment has been minimized.

Show comment
Hide comment
@kaystrobach

kaystrobach Jun 22, 2015

ok, lets close it for now, still believe longer keys are better 😄

kaystrobach commented Jun 22, 2015

ok, lets close it for now, still believe longer keys are better 😄

@lewisgoddard

This comment has been minimized.

Show comment
Hide comment
@lewisgoddard

lewisgoddard Jun 22, 2015

@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.

@jdkasten

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.

RSA Decryption Time by Key Length
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.

lewisgoddard commented Jun 22, 2015

@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.

@jdkasten

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.

RSA Decryption Time by Key Length
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.

@evrial

This comment has been minimized.

Show comment
Hide comment
@evrial

evrial Sep 3, 2015

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

evrial commented Sep 3, 2015

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

@J0WI

This comment has been minimized.

Show comment
Hide comment
@J0WI

J0WI Oct 21, 2015

For AES-128 equal strength we should use a >= 3072 bit RSA private key (15360 bit for AES-256).

J0WI commented Oct 21, 2015

For AES-128 equal strength we should use a >= 3072 bit RSA private key (15360 bit for AES-256).

@zestysoft

This comment has been minimized.

Show comment
Hide comment
@zestysoft

zestysoft Oct 24, 2015

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."

Source:
https://community.qualys.com/thread/11386

zestysoft commented Oct 24, 2015

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."

Source:
https://community.qualys.com/thread/11386

@tomtastic

This comment has been minimized.

Show comment
Hide comment
@tomtastic

tomtastic Nov 4, 2015

[Retracted comment as I had missed the option to specify '--rsa-key-size 4096']
Still believe it should be the default though...

tomtastic commented Nov 4, 2015

[Retracted comment as I had missed the option to specify '--rsa-key-size 4096']
Still believe it should be the default though...

@jooize

This comment has been minimized.

Show comment
Hide comment
@jooize

jooize Nov 4, 2015

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.

@jdkasten

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.

@jdkasten

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!

jooize commented Nov 4, 2015

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.

@jdkasten

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.

@jdkasten

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!

@MattiSG

This comment has been minimized.

Show comment
Hide comment
@MattiSG

MattiSG Dec 14, 2015

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?

MattiSG commented Dec 14, 2015

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?

@tazeat

This comment has been minimized.

Show comment
Hide comment
@tazeat

tazeat Dec 15, 2015

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.

tazeat commented Dec 15, 2015

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.

@jooize

This comment has been minimized.

Show comment
Hide comment
@jooize

jooize Dec 15, 2015

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

jooize commented Dec 15, 2015

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

@lope

This comment has been minimized.

Show comment
Hide comment
@lope

lope Jan 9, 2016

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.

lope commented Jan 9, 2016

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.

@wjordan

This comment has been minimized.

Show comment
Hide comment
@wjordan

wjordan Mar 19, 2016

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.

wjordan commented Mar 19, 2016

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.

@nitmir

This comment has been minimized.

Show comment
Hide comment
@nitmir

nitmir Mar 21, 2016

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).

nitmir commented Mar 21, 2016

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).

@nzkarit

This comment has been minimized.

Show comment
Hide comment
@nzkarit

nzkarit Apr 24, 2016

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)

nzkarit commented Apr 24, 2016

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)

@jult

This comment has been minimized.

Show comment
Hide comment
@jult

jult Jan 17, 2017

@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 commented Jan 17, 2017

@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..

@lewisgoddard

This comment has been minimized.

Show comment
Hide comment
@lewisgoddard

lewisgoddard Jan 17, 2017

@jult I am fairly certain that Certbot does that automatically, which was their point.

lewisgoddard commented Jan 17, 2017

@jult I am fairly certain that Certbot does that automatically, which was their point.

@jult

This comment has been minimized.

Show comment
Hide comment
@jult

jult Jan 17, 2017

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.

jult commented Jan 17, 2017

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.

@ArchangeGabriel

This comment has been minimized.

Show comment
Hide comment
@ArchangeGabriel

ArchangeGabriel Jan 17, 2017

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.

ArchangeGabriel commented Jan 17, 2017

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.

@baijianpeng

This comment has been minimized.

Show comment
Hide comment
@baijianpeng

baijianpeng Dec 16, 2017

Agree. 4096 length should be the default rsa-key-size.

baijianpeng commented Dec 16, 2017

Agree. 4096 length should be the default rsa-key-size.

@cromefire

This comment has been minimized.

Show comment
Hide comment
@cromefire

cromefire Aug 10, 2018

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.

cromefire commented Aug 10, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment