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 3072 #2080

Open
HLFH opened this Issue Jan 4, 2016 · 47 comments

Comments

Projects
None yet
@HLFH

HLFH commented Jan 4, 2016

According to NSA and ANSSI, RSA with 3072 bit-modulus is the minimum to protect up to TOP SECRET.

We should not be in the red line of cryptography. This security by default will bring the needed protection for all the Internet users that pass by HTTP webservers powered with Let's Encrypt.

@mgollo

This comment has been minimized.

Show comment
Hide comment
@mgollo

mgollo Jan 4, 2016

I would even suggest 4096 (I do it on almost all of my systems).

Thanks,
Martin

mgollo commented Jan 4, 2016

I would even suggest 4096 (I do it on almost all of my systems).

Thanks,
Martin

@HLFH

This comment has been minimized.

Show comment
Hide comment
@HLFH

HLFH Jan 4, 2016

I would suggest also 4096.

But some months ago, they disagree with 4096 by default: #489

I prefer a compromise (= RSA with 3072 bit-modulus) compared to no security at all by default.

HLFH commented Jan 4, 2016

I would suggest also 4096.

But some months ago, they disagree with 4096 by default: #489

I prefer a compromise (= RSA with 3072 bit-modulus) compared to no security at all by default.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 4, 2016

Suggest 4096 too.
Security must be good by design and default : no standard user change the default configuration.

And there is no acceptable argument for 2048/3072 vs 4096 bits (only a very small speed overhead).
3072 bits can lead to compatibility problem if user agent hardcode some key sizes (2048 and 4096 bits will be better supported than 3072).

Worst, argument of the 90 days key regeneration to justify 2048 bits key usage is not good :

  • Key regeneration breaks a lot of others TLS stack protection, like DANE/TLSA or HPKP, hardened configuration must disable it to avoid big trouble.
  • Key regeneration doesn’t say "destruction of the past". If the web server is not configured correctly with only PFS ciphers suite, NSA-like agencies can intercept and store network communication protected with 2048 bits key, and can decrypt them in 20 or 30 years, even if the corresponding keys were destroy. 4096 bits keys protect longer non PFS communication.
  • Even with PFS only ciphers, web servers generally base the negociated DH parameter on the private key size. If you use only 2048 bits private key, your DH parameter is 2048 bits only, and so possible weak to LogJam.

aeris commented Jan 4, 2016

Suggest 4096 too.
Security must be good by design and default : no standard user change the default configuration.

And there is no acceptable argument for 2048/3072 vs 4096 bits (only a very small speed overhead).
3072 bits can lead to compatibility problem if user agent hardcode some key sizes (2048 and 4096 bits will be better supported than 3072).

Worst, argument of the 90 days key regeneration to justify 2048 bits key usage is not good :

  • Key regeneration breaks a lot of others TLS stack protection, like DANE/TLSA or HPKP, hardened configuration must disable it to avoid big trouble.
  • Key regeneration doesn’t say "destruction of the past". If the web server is not configured correctly with only PFS ciphers suite, NSA-like agencies can intercept and store network communication protected with 2048 bits key, and can decrypt them in 20 or 30 years, even if the corresponding keys were destroy. 4096 bits keys protect longer non PFS communication.
  • Even with PFS only ciphers, web servers generally base the negociated DH parameter on the private key size. If you use only 2048 bits private key, your DH parameter is 2048 bits only, and so possible weak to LogJam.
@k0nsl

This comment has been minimized.

Show comment
Hide comment
@k0nsl

k0nsl Jan 4, 2016

Another +1 for 4096, that's what I always use these days.

k0nsl commented Jan 4, 2016

Another +1 for 4096, that's what I always use these days.

@bmw

This comment has been minimized.

Show comment
Hide comment
@bmw

bmw Jan 8, 2016

Contributor

See #489 for a lot of discussion about this issue.

Contributor

bmw commented Jan 8, 2016

See #489 for a lot of discussion about this issue.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

With LE's default settings, RSA 2048 bits, 90 days, try to crack it? I suggest to close this issue.

ghost commented Jan 22, 2016

With LE's default settings, RSA 2048 bits, 90 days, try to crack it? I suggest to close this issue.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

Question is not « proof you can crack it » (or stay at 1024 bits, nobody crack it since now) but « all recommendation / state of the art ask for at least 3072 bits » (NSA, NIST, ANSSI, FIPS, Qualys and more).
There is NO valid drawbacks to upgrade to 4096 bits by default.

(And I repeat, even with 90 days key renew, if no PFS used, you have a practical key validity of plenty decades even if technical validity is only 90 days, and 90 days key renew breaks a lot of other TLS stack (TLSA, HPKP, cert pinning), so sane sys admin MUST disable it and reuse a key for at least 120 days and 1 year in practice)

aeris commented Jan 22, 2016

Question is not « proof you can crack it » (or stay at 1024 bits, nobody crack it since now) but « all recommendation / state of the art ask for at least 3072 bits » (NSA, NIST, ANSSI, FIPS, Qualys and more).
There is NO valid drawbacks to upgrade to 4096 bits by default.

(And I repeat, even with 90 days key renew, if no PFS used, you have a practical key validity of plenty decades even if technical validity is only 90 days, and 90 days key renew breaks a lot of other TLS stack (TLSA, HPKP, cert pinning), so sane sys admin MUST disable it and reuse a key for at least 120 days and 1 year in practice)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

However, in the Alexa top 1,000,000 websites, over 89% of SSL/TLS enabled websites use RSA 2048 bits, including many online banking websites.

ghost commented Jan 22, 2016

However, in the Alexa top 1,000,000 websites, over 89% of SSL/TLS enabled websites use RSA 2048 bits, including many online banking websites.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

Yep, bank have also SSLv3 and MD5 if you want https://imirhil.fr/tls/#Banques%20en%20ligne
And Google/Youtube too https://imirhil.fr/tls/alexa.html
And porn site no TLS at all https://imirhil.fr/tls/porn.html
Even CA have SSLv3, MD5, RC4 or SSLv2 (yep, you read correctly…) and 40 bits EXPORT suites https://imirhil.fr/tls/ca.html

TLS configuration are VERY bad in the wild, this is not a plea to continue to do craps.

aeris commented Jan 22, 2016

Yep, bank have also SSLv3 and MD5 if you want https://imirhil.fr/tls/#Banques%20en%20ligne
And Google/Youtube too https://imirhil.fr/tls/alexa.html
And porn site no TLS at all https://imirhil.fr/tls/porn.html
Even CA have SSLv3, MD5, RC4 or SSLv2 (yep, you read correctly…) and 40 bits EXPORT suites https://imirhil.fr/tls/ca.html

TLS configuration are VERY bad in the wild, this is not a plea to continue to do craps.

@HLFH

This comment has been minimized.

Show comment
Hide comment
@HLFH

HLFH Jan 22, 2016

@devnsec-com So they are not secure. Even if IPv6 and DNSSEC are good technologies, they are not massively deployed yet. It happens the same for RSA 4096 bits. We have to move forward instead of treading water.

HLFH commented Jan 22, 2016

@devnsec-com So they are not secure. Even if IPv6 and DNSSEC are good technologies, they are not massively deployed yet. It happens the same for RSA 4096 bits. We have to move forward instead of treading water.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

The only reason to use RSA 3072 or 4096 (or even longer) is future proofing, but with a 90 days only certificate, do all users really need RSA longer than 2048 by default? If you are really paranoid, go for longer keys, there is a parameter and you can change it.

ghost commented Jan 22, 2016

The only reason to use RSA 3072 or 4096 (or even longer) is future proofing, but with a 90 days only certificate, do all users really need RSA longer than 2048 by default? If you are really paranoid, go for longer keys, there is a parameter and you can change it.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

All user need 3072+ key by default.

People really knowing what they do can eventually reduce the size, but by default, Let’s encrypt must provide state of the art compliant configuration.
Standard user (99% in fact) don’t even look into the config or care about the size of the generated key or even know what TLS really is…

aeris commented Jan 22, 2016

All user need 3072+ key by default.

People really knowing what they do can eventually reduce the size, but by default, Let’s encrypt must provide state of the art compliant configuration.
Standard user (99% in fact) don’t even look into the config or care about the size of the generated key or even know what TLS really is…

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

Remember, we are talking about a SSL/TLS certificate, you can have PFS support on your server, and it can be revoked if necessary. We are not talking about an OpenGPG key or SSH key which you could use them for 20 years or even longer.

And many years later, when RSA 2048 is actually being proved no longer secure, we can change LE defaults to RSA 4096, nearly all users will be changed to RSA 4096 within 90 days.

ghost commented Jan 22, 2016

Remember, we are talking about a SSL/TLS certificate, you can have PFS support on your server, and it can be revoked if necessary. We are not talking about an OpenGPG key or SSH key which you could use them for 20 years or even longer.

And many years later, when RSA 2048 is actually being proved no longer secure, we can change LE defaults to RSA 4096, nearly all users will be changed to RSA 4096 within 90 days.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

Since I've mentioned OpenGPG, I'd say that even OpenGPG is default to RSA 2048.
Read this: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

ghost commented Jan 22, 2016

Since I've mentioned OpenGPG, I'd say that even OpenGPG is default to RSA 2048.
Read this: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

You can. You can have not PFS too. And if 2048 bits key, you’re not secure. Even with 90d renew. And if no PFS, key destruction is useless, your datas are already in nature and should be decrypted in few decades.

And only certificate can be revoked, not key.
Keys are exactly like GPG/SSH key : after generation, you have to handle them til physical destruction of the surface of the earth if PFS and eternally if no PFS.

aeris commented Jan 22, 2016

You can. You can have not PFS too. And if 2048 bits key, you’re not secure. Even with 90d renew. And if no PFS, key destruction is useless, your datas are already in nature and should be decrypted in few decades.

And only certificate can be revoked, not key.
Keys are exactly like GPG/SSH key : after generation, you have to handle them til physical destruction of the surface of the earth if PFS and eternally if no PFS.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

Since I've mentioned OpenGPG, I'd say that even OpenGPG is default to RSA 2048.

GPG have real drawback to use 4096 keys (only few smartcard support more than 2048, mobile device…). On TLS, there is none.

And on GPG, everybody currently generate 4096 bits keys, all tutorials and recommandations ask for it.

aeris commented Jan 22, 2016

Since I've mentioned OpenGPG, I'd say that even OpenGPG is default to RSA 2048.

GPG have real drawback to use 4096 keys (only few smartcard support more than 2048, mobile device…). On TLS, there is none.

And on GPG, everybody currently generate 4096 bits keys, all tutorials and recommandations ask for it.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

You have just made a point, instead of arguing default to RSA 2048 or longer, we should talking about default to enable PFS. Because no matter how long the key is, it will be decrypted soon or later, RSA 2048 will, RSA 4096 will too.

ghost commented Jan 22, 2016

You have just made a point, instead of arguing default to RSA 2048 or longer, we should talking about default to enable PFS. Because no matter how long the key is, it will be decrypted soon or later, RSA 2048 will, RSA 4096 will too.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

Yep, but you have no way to ensure PFS with Let’s Encrypt (and worse only PFS ciphers, you can negociate a PFS cipher suite but server can support no-PFS or EXPORT…).

And currently, there are major drawback to use only PFS cipher suites (browser compatibility, see https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA).

In all cases, this is not the job of a CA.

aeris commented Jan 22, 2016

Yep, but you have no way to ensure PFS with Let’s Encrypt (and worse only PFS ciphers, you can negociate a PFS cipher suite but server can support no-PFS or EXPORT…).

And currently, there are major drawback to use only PFS cipher suites (browser compatibility, see https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA).

In all cases, this is not the job of a CA.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

We are not talking about CA here, but a client software, right?

ghost commented Jan 22, 2016

We are not talking about CA here, but a client software, right?

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

No. TLS is very complicated, with a lot of stack.
No software can handle it completely.

You have no way to guess if your user have DNSSec or TLSA, must ensure IE compatibility or not standard user-agent, what version of OpenSSL is used, etc.
The only thing LE can do is to raise key size…

aeris commented Jan 22, 2016

No. TLS is very complicated, with a lot of stack.
No software can handle it completely.

You have no way to guess if your user have DNSSec or TLSA, must ensure IE compatibility or not standard user-agent, what version of OpenSSL is used, etc.
The only thing LE can do is to raise key size…

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 22, 2016

No, when LE uses RSA 3072 or 4096 by default, someone will say he wants RSA 8192 by default for all users, this is an endless arms race.

ghost commented Jan 22, 2016

No, when LE uses RSA 3072 or 4096 by default, someone will say he wants RSA 8192 by default for all users, this is an endless arms race.

@HLFH

This comment has been minimized.

Show comment
Hide comment
@HLFH

HLFH Jan 22, 2016

@devnsec-com No. NSA, NIST, ANSSI, FIPS, Qualys don't recommend RSA 8192 but at least RSA 3072.

HLFH commented Jan 22, 2016

@devnsec-com No. NSA, NIST, ANSSI, FIPS, Qualys don't recommend RSA 8192 but at least RSA 3072.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 22, 2016

No, if somebody ask for 8192, you can say 4096 is currently safe and recommanded everywhere.
Currently, this is not the case of 2048.

aeris commented Jan 22, 2016

No, if somebody ask for 8192, you can say 4096 is currently safe and recommanded everywhere.
Currently, this is not the case of 2048.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 23, 2016

I can also say Yubico, Cisco, and many companies are recommending RSA 2048 at the time we are speaking.

The longer the key length the safer they are, but business companies are more pragmatic on this topic. Again, RSA 2048 is enough at current stage as a default, as long as we support longer key when needed.

ghost commented Jan 23, 2016

I can also say Yubico, Cisco, and many companies are recommending RSA 2048 at the time we are speaking.

The longer the key length the safer they are, but business companies are more pragmatic on this topic. Again, RSA 2048 is enough at current stage as a default, as long as we support longer key when needed.

@rmhrisk

This comment has been minimized.

Show comment
Hide comment
@rmhrisk

rmhrisk Jan 23, 2016

Good resource for this conversation - keylength.com

rmhrisk commented Jan 23, 2016

Good resource for this conversation - keylength.com

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 23, 2016

@devnsec-com Yubico and Cisco position are valid, because they have hardware issue (HSM, PKI and smartcard don’t support 4096 bits very well).

From Yubico : « This is not a constraint from Yubico, but rather a hardware limitation of the NXP A700x chip used within the YubiKeys »
From Cisco : 4096 bits only available from Cisco IOS XE Release 2.4 (and hardware are difficult to upgrade), and the given page is very old (seems not updated since 2.4 release (2009), same default value since at least 2.X release…).

And this is not because all the other sheeps are running towards the cliff that we must follow thew…

aeris commented Jan 23, 2016

@devnsec-com Yubico and Cisco position are valid, because they have hardware issue (HSM, PKI and smartcard don’t support 4096 bits very well).

From Yubico : « This is not a constraint from Yubico, but rather a hardware limitation of the NXP A700x chip used within the YubiKeys »
From Cisco : 4096 bits only available from Cisco IOS XE Release 2.4 (and hardware are difficult to upgrade), and the given page is very old (seems not updated since 2.4 release (2009), same default value since at least 2.X release…).

And this is not because all the other sheeps are running towards the cliff that we must follow thew…

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 23, 2016

@devnsec-com I add too that Cisco documentation is about PKI and CA management, and in this field (CA cert, not end user cert), CA/B-forum recommends at least 2048 bits.

And there is internal debate about 4096 inclusions too, since 2014.

Would we include recommendation on key size? Some people intentionally want to use 4096 bit key. Would they take advice? The document could explain the trade-off between security, compatibility, and other factors

But seems hardware routers don’t support roots more than 2048 (Cisco)

Iñigo said that Cisco’s latest products don’t support SHA-1 and 4096-bit roots. Kelvin said he could try to work with Cisco to change that.

aeris commented Jan 23, 2016

@devnsec-com I add too that Cisco documentation is about PKI and CA management, and in this field (CA cert, not end user cert), CA/B-forum recommends at least 2048 bits.

And there is internal debate about 4096 inclusions too, since 2014.

Would we include recommendation on key size? Some people intentionally want to use 4096 bit key. Would they take advice? The document could explain the trade-off between security, compatibility, and other factors

But seems hardware routers don’t support roots more than 2048 (Cisco)

Iñigo said that Cisco’s latest products don’t support SHA-1 and 4096-bit roots. Kelvin said he could try to work with Cisco to change that.

@aeris

This comment has been minimized.

Show comment
Hide comment
@aeris

aeris Jan 23, 2016

@devnsec-com Another internal comment on CA/B-forum.

Setting target dates for the next set of changes for improved security/performance (RSA-4096/ECC/SHA-512/etc)

aeris commented Jan 23, 2016

@devnsec-com Another internal comment on CA/B-forum.

Setting target dates for the next set of changes for improved security/performance (RSA-4096/ECC/SHA-512/etc)

@FlorentATo

This comment has been minimized.

Show comment
Hide comment
@FlorentATo

FlorentATo Feb 1, 2016

Hello guys, It would be great to keep this thread going and hear back from LE staff.
As far as I can read, @aeris arguments seem to be valid and not contradicted. Except if we missed something, I also expect LE to switch default RSA key to 4096bits soon.

FlorentATo commented Feb 1, 2016

Hello guys, It would be great to keep this thread going and hear back from LE staff.
As far as I can read, @aeris arguments seem to be valid and not contradicted. Except if we missed something, I also expect LE to switch default RSA key to 4096bits soon.

@chort

This comment has been minimized.

Show comment
Hide comment
@chort

chort Feb 10, 2016

+1 for RSA 3072bit by default.

As has been mentioned, RSA 2048bit is only equivalent to 112bits of symmetric key protection. That falls below the widely-held minimum of 128bit used today. RSA 3072bit is only 128bit equivalent, so sufficient for right now (and the bare minimum recommended by the NSA as of January, 2016).

Note that all previous estimates of longevity for key sizes should be taken with healthy skepticism, because they generally assume a linear improvement in key-breaking, but new attacks can decrease security much more quickly.

chort commented Feb 10, 2016

+1 for RSA 3072bit by default.

As has been mentioned, RSA 2048bit is only equivalent to 112bits of symmetric key protection. That falls below the widely-held minimum of 128bit used today. RSA 3072bit is only 128bit equivalent, so sufficient for right now (and the bare minimum recommended by the NSA as of January, 2016).

Note that all previous estimates of longevity for key sizes should be taken with healthy skepticism, because they generally assume a linear improvement in key-breaking, but new attacks can decrease security much more quickly.

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

@DXGLdotinfo

This comment has been minimized.

Show comment
Hide comment
@DXGLdotinfo

DXGLdotinfo Aug 20, 2016

Anyone who wishes to have greater than 2048 bits RSA can simply enter --rsa-key-size 3072 or --rsa-key-size 4096 to request these key sizes.
Please note that larger RSA keys take exponentially longer to generate, and anything larger than 4096 can crash older Apple browsers.

DXGLdotinfo commented Aug 20, 2016

Anyone who wishes to have greater than 2048 bits RSA can simply enter --rsa-key-size 3072 or --rsa-key-size 4096 to request these key sizes.
Please note that larger RSA keys take exponentially longer to generate, and anything larger than 4096 can crash older Apple browsers.

@J0WI

This comment has been minimized.

Show comment
Hide comment
@J0WI

J0WI Aug 20, 2016

When #2632 has been implemented the performance drawback will have nearly no impact for the majority.
So we can combine EC 256 with 3072 RSA (or what ever we prefer as default) to provide equal strength for both.

J0WI commented Aug 20, 2016

When #2632 has been implemented the performance drawback will have nearly no impact for the majority.
So we can combine EC 256 with 3072 RSA (or what ever we prefer as default) to provide equal strength for both.

@DXGLdotinfo

This comment has been minimized.

Show comment
Hide comment
@DXGLdotinfo

DXGLdotinfo Aug 20, 2016

By the way, as a suggestion to support EC keys, have a command like --ec-key-type to generate an EC key and request the certificate.
I currently generate and get signed my RSA keys using certbot and my EC keys using a shell script.

DXGLdotinfo commented Aug 20, 2016

By the way, as a suggestion to support EC keys, have a command like --ec-key-type to generate an EC key and request the certificate.
I currently generate and get signed my RSA keys using certbot and my EC keys using a shell script.

@J0WI

This comment has been minimized.

Show comment
Hide comment
@J0WI

J0WI Aug 20, 2016

@WilliamFeely that's #2625

J0WI commented Aug 20, 2016

@WilliamFeely that's #2625

@DXGLdotinfo

This comment has been minimized.

Show comment
Hide comment
@DXGLdotinfo

DXGLdotinfo Aug 20, 2016

Thanks.
As for the RSA key size, I am guessing RSA 2048 is still industry standard, and still authorized for PCI-DSS compliance, and thus why it is still default?

DXGLdotinfo commented Aug 20, 2016

Thanks.
As for the RSA key size, I am guessing RSA 2048 is still industry standard, and still authorized for PCI-DSS compliance, and thus why it is still default?

@FlorentATo

This comment has been minimized.

Show comment
Hide comment
@FlorentATo

FlorentATo Aug 31, 2016

Here's what the latest PCI-DSS documentation (v3.2, April 2016) says:

Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g. NIST SP 800-52 and SP 800-57, OWASP, etc.)

Fortunately, the glossary defines Strong Cryptography as follow:

Cryptography based on industry-tested and accepted algorithms, along with key lengths that provide a minimum of 112-bits of effective key strength and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is “one way”; that is, not reversible). See Hashing.

At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See the current version of NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.

Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction- based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure.
It is recommended that all new implementations use a minimum of 128-bits of effective key strength.

FlorentATo commented Aug 31, 2016

Here's what the latest PCI-DSS documentation (v3.2, April 2016) says:

Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g. NIST SP 800-52 and SP 800-57, OWASP, etc.)

Fortunately, the glossary defines Strong Cryptography as follow:

Cryptography based on industry-tested and accepted algorithms, along with key lengths that provide a minimum of 112-bits of effective key strength and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is “one way”; that is, not reversible). See Hashing.

At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See the current version of NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.

Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction- based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure.
It is recommended that all new implementations use a minimum of 128-bits of effective key strength.

@AliceWonderMiscreations

This comment has been minimized.

Show comment
Hide comment
@AliceWonderMiscreations

AliceWonderMiscreations Sep 29, 2016

There is no need to default to 3072 for an RSA key used with a web server.

First of all, you should only be using ciphers that provide FS. This way past sessions that are logged are still secure even if your private key is later discovered.

With something like GnuPG you may want to use larger (I use 4096) because FS is not an option, the client and server don't negotiate their own key when the connection is established. Even with GnuPG you really don't need > 2048 and if you do, EC gives more bang for the buck, but since it isn't well supported yet by clients and a GnuPG encrypted message may be sensitive for decades, 4096 is at least justifiable,

It is not justifiable with HTTPS if FS is used. When FS is used, you should use ECDHE ciphers when possible so that they key used between client and server is stronger. If your server still supports DHE keys then it is the DH group where you should worry about how many bits, and there, most people use the pre-defined 2048 DH group that is published in the RFC. Generating your own 2048 bit DHE group is reasonable.

For the server private key, 2048 bit can not be easily cracked and therefore is sufficient. Suggesting a default of 3072 or 4096 is like suggesting a 20 pound paperweight instead of 15 pound. Yes the 20 pound is heavier but no there is no real benefit and your 2048 bit RSA key will be long long long replaced before it is no longer safe.

Always use forward secrecy and use ECDHE ciphers whenever possible. The private key, RSA 2048 is good enough and if you really want better, use ECDSA not RSA for the key.

AliceWonderMiscreations commented Sep 29, 2016

There is no need to default to 3072 for an RSA key used with a web server.

First of all, you should only be using ciphers that provide FS. This way past sessions that are logged are still secure even if your private key is later discovered.

With something like GnuPG you may want to use larger (I use 4096) because FS is not an option, the client and server don't negotiate their own key when the connection is established. Even with GnuPG you really don't need > 2048 and if you do, EC gives more bang for the buck, but since it isn't well supported yet by clients and a GnuPG encrypted message may be sensitive for decades, 4096 is at least justifiable,

It is not justifiable with HTTPS if FS is used. When FS is used, you should use ECDHE ciphers when possible so that they key used between client and server is stronger. If your server still supports DHE keys then it is the DH group where you should worry about how many bits, and there, most people use the pre-defined 2048 DH group that is published in the RFC. Generating your own 2048 bit DHE group is reasonable.

For the server private key, 2048 bit can not be easily cracked and therefore is sufficient. Suggesting a default of 3072 or 4096 is like suggesting a 20 pound paperweight instead of 15 pound. Yes the 20 pound is heavier but no there is no real benefit and your 2048 bit RSA key will be long long long replaced before it is no longer safe.

Always use forward secrecy and use ECDHE ciphers whenever possible. The private key, RSA 2048 is good enough and if you really want better, use ECDSA not RSA for the key.

@AliceWonderMiscreations

This comment has been minimized.

Show comment
Hide comment
@AliceWonderMiscreations

AliceWonderMiscreations Sep 29, 2016

I guess what I'm trying to say, and correct me if I am wrong, is that when your TLS requires ciphers that use Forward Secrecy then the only real purpose of the server long term private key is identity.

The actual encryption between client and server that takes places uses a temporary key negotiated between client and server that is unrelated to the key used with the x.509 certificate.

That's what you need to worry about, never using DH parameters < 2048 and preferably using ECDHE. The private key for the server then only has relevance in establishing the identity of the server, and 2048 bit RSA is certainly good enough for that especially if you follow best practices to generate a fresh key at least once a year.

Thus this issue should be closed, and the emphasis on security should be placed on proper cipher suite selection.

AliceWonderMiscreations commented Sep 29, 2016

I guess what I'm trying to say, and correct me if I am wrong, is that when your TLS requires ciphers that use Forward Secrecy then the only real purpose of the server long term private key is identity.

The actual encryption between client and server that takes places uses a temporary key negotiated between client and server that is unrelated to the key used with the x.509 certificate.

That's what you need to worry about, never using DH parameters < 2048 and preferably using ECDHE. The private key for the server then only has relevance in establishing the identity of the server, and 2048 bit RSA is certainly good enough for that especially if you follow best practices to generate a fresh key at least once a year.

Thus this issue should be closed, and the emphasis on security should be placed on proper cipher suite selection.

@jult

This comment has been minimized.

Show comment
Hide comment
@jult

jult Jan 17, 2017

Interesting, but when both Applebaum and Snowden recommend me to use RSA key size 4096 bit, well, hmm, I don't know, I think I might just follow up on that advice. Isn't identity precisely what we're trying to hide/protect here?

jult commented Jan 17, 2017

Interesting, but when both Applebaum and Snowden recommend me to use RSA key size 4096 bit, well, hmm, I don't know, I think I might just follow up on that advice. Isn't identity precisely what we're trying to hide/protect here?

@ageis

This comment has been minimized.

Show comment
Hide comment
@ageis

ageis Aug 27, 2017

@jult Just stick with 4096-bit, especially if you're using GnuPG. Not until everyone upgrades to 2.1 will we have access to ed25519 OpenPGP keys. and they're not that much stronger. (I do love my ed25519 SSH + GPG keys, so do encourage everyone to move away from RSA!)

2048-bit RSA keys are expected to be breakable by an attacker with a large amount of computational resources within the next years or so. 768-1024 bits already broken routinely.

I don't think 3072 is a reasonable default, it's kind of out of the ordinary.

ageis commented Aug 27, 2017

@jult Just stick with 4096-bit, especially if you're using GnuPG. Not until everyone upgrades to 2.1 will we have access to ed25519 OpenPGP keys. and they're not that much stronger. (I do love my ed25519 SSH + GPG keys, so do encourage everyone to move away from RSA!)

2048-bit RSA keys are expected to be breakable by an attacker with a large amount of computational resources within the next years or so. 768-1024 bits already broken routinely.

I don't think 3072 is a reasonable default, it's kind of out of the ordinary.

@ageis

This comment has been minimized.

Show comment
Hide comment
@ageis

ageis Aug 27, 2017

2048-bit will not be recommended past 2030, I guarantee you, and the sunset will be gradual like it was for SHA-1. I've read plenty of those government standards documents and such...

For a while people were in the practice of making 8192-bit keys and above... It's only a fun two or three-line change to the source, I'm not sure how well operable they are with others though.

.@WikiLeaks publishes an unusually strong 8192-bit RSA PGP encryption key for submissions https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

— K.M. Gallagher (@ageis) May 27, 2015

@ageis Also, there's a fairly hard limit on 16384. It would require *a lot* more hacking to go bigger; I tried.

— isis agora lovecruft (@isislovecruft) September 8, 2014

@jult I won't address the Appelbaum and Snowden thing. I'm loosely acquainted with them too but I see it as a sort've rock-star appeal to authority you're making. Look at all sources, I can recommend a few especially:

Personally, I'm more keen on getting everybody updated to GnuPG 2.1, with the faster kbx format, and generating new ed25519 keys (thoughts @dkg or @floodyberry?), and it's my hope that the next Yubico series will support them. In fact I can reach out to check; as I did some beta testing for the YubiKey 4. I don't like how keys must be protected/passworded to be exported however, because it makes importation to the smartcard a challenge.

While I'm around this issue, I'll drop a great chart from NIST Special Publication 800-57. Many more where that came from. Perfect thing to be starting at on a Saturday night, huh?

nist_table

ageis commented Aug 27, 2017

2048-bit will not be recommended past 2030, I guarantee you, and the sunset will be gradual like it was for SHA-1. I've read plenty of those government standards documents and such...

For a while people were in the practice of making 8192-bit keys and above... It's only a fun two or three-line change to the source, I'm not sure how well operable they are with others though.

.@WikiLeaks publishes an unusually strong 8192-bit RSA PGP encryption key for submissions https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

— K.M. Gallagher (@ageis) May 27, 2015

@ageis Also, there's a fairly hard limit on 16384. It would require *a lot* more hacking to go bigger; I tried.

— isis agora lovecruft (@isislovecruft) September 8, 2014

@jult I won't address the Appelbaum and Snowden thing. I'm loosely acquainted with them too but I see it as a sort've rock-star appeal to authority you're making. Look at all sources, I can recommend a few especially:

Personally, I'm more keen on getting everybody updated to GnuPG 2.1, with the faster kbx format, and generating new ed25519 keys (thoughts @dkg or @floodyberry?), and it's my hope that the next Yubico series will support them. In fact I can reach out to check; as I did some beta testing for the YubiKey 4. I don't like how keys must be protected/passworded to be exported however, because it makes importation to the smartcard a challenge.

While I'm around this issue, I'll drop a great chart from NIST Special Publication 800-57. Many more where that came from. Perfect thing to be starting at on a Saturday night, huh?

nist_table

@jult

This comment has been minimized.

Show comment
Hide comment
@jult

jult Nov 16, 2017

Again, the extra load on size during client-handshake is not worth the extra risk with a smaller keysize. The ones recommending against using 4096 bits RSA fail to come up with valid arguments not to. Not to mention the fact that we're relying on proper generation of the keys, and if ever that ends up being flawed, we're way better off with 4096 bits keys.
Check this; #489 (comment)
You want to make sure you generate Diffie Helman keys of >=4096 bits as well, stuff like this
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
if you want it to make any sense when you've enabled DH(E) in your cypher suites.

jult commented Nov 16, 2017

Again, the extra load on size during client-handshake is not worth the extra risk with a smaller keysize. The ones recommending against using 4096 bits RSA fail to come up with valid arguments not to. Not to mention the fact that we're relying on proper generation of the keys, and if ever that ends up being flawed, we're way better off with 4096 bits keys.
Check this; #489 (comment)
You want to make sure you generate Diffie Helman keys of >=4096 bits as well, stuff like this
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
if you want it to make any sense when you've enabled DH(E) in your cypher suites.

@schoen

This comment has been minimized.

Show comment
Hide comment
@schoen

schoen Oct 15, 2018

Contributor

I ran a synthetic benchmark for RSA signatures just now and saw this:

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

The first number is the modulus size and the second is the average number of seconds required per signature operation.

Contributor

schoen commented Oct 15, 2018

I ran a synthetic benchmark for RSA signatures just now and saw this:

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

The first number is the modulus size and the second is the average number of seconds required per signature operation.

@schoen

This comment has been minimized.

Show comment
Hide comment
@schoen

schoen Oct 15, 2018

Contributor

I found @AliceWonderMiscreations's comments about forward secrecy somewhat persuasive; does anyone happen to have some current statistics about the fractions of TLS connections which are negotiated with various ciphersuites today? If very few are now using non-PFS ciphers, then the RSA key length parameter will have minimal long-term security consequences.

Contributor

schoen commented Oct 15, 2018

I found @AliceWonderMiscreations's comments about forward secrecy somewhat persuasive; does anyone happen to have some current statistics about the fractions of TLS connections which are negotiated with various ciphersuites today? If very few are now using non-PFS ciphers, then the RSA key length parameter will have minimal long-term security consequences.

@dkg

This comment has been minimized.

Show comment
Hide comment
@dkg

dkg Oct 15, 2018

FS and non-FS is a separate issue. Yes, we should encourage FS ciphersuites, and both clients and servers should be disabling non-FS ciphersuites where they know it to be possible to do so. (TLS 1.3 has no non-FS ciphersuites left, yay!) That doesn't mean that we should ignore the importance of a strong cryptographic identity key, or that we should play one off against the other. Remember that a forged identity key makes it possible to MiTM even a FS connection.

RSA 3072 appears to be the sweet spot where recommendations (like ENISA and NIST) come down on a strong security margin for keys intended for use over the next decade.

dkg commented Oct 15, 2018

FS and non-FS is a separate issue. Yes, we should encourage FS ciphersuites, and both clients and servers should be disabling non-FS ciphersuites where they know it to be possible to do so. (TLS 1.3 has no non-FS ciphersuites left, yay!) That doesn't mean that we should ignore the importance of a strong cryptographic identity key, or that we should play one off against the other. Remember that a forged identity key makes it possible to MiTM even a FS connection.

RSA 3072 appears to be the sweet spot where recommendations (like ENISA and NIST) come down on a strong security margin for keys intended for use over the next decade.

@schoen

This comment has been minimized.

Show comment
Hide comment
@schoen

schoen Oct 16, 2018

Contributor

Hi @dkg,

FS and non-FS is a separate issue. Yes, we should encourage FS ciphersuites, and both clients and servers should be disabling non-FS ciphersuites where they know it to be possible to do so. (TLS 1.3 has no non-FS ciphersuites left, yay!) That doesn't mean that we should ignore the importance of a strong cryptographic identity key, or that we should play one off against the other. Remember that a forged identity key makes it possible to MiTM even a FS connection.

In the default case, we currently only use an individual RSA subject key for 60 days (with the active MITM risk continuing for the 90-day lifetime of the certificate), and then switch to a different one. It seems like there's a considerable difference between "an attacker who can break the 2048-bit key in 90 days can perform an active attack" and "an attacker who can break the 2048-bit key at any time can recover plaintext of old sessions that it was involved in". The former is true and the latter is not true in the case of FS ciphersuites.

The recommendations about keylength typically seem to assume a threat model in which the attacker breaks a key some time after that key is used—for example the recommendations that you mention below appear to be based on a threat model in which an attacker takes years to break an individual key. With FS ciphersuites, that threat model shouldn't be that relevant for deciding the length of the identity key because a given identity key has long since ceased to be used.

RSA 3072 appears to be the sweet spot where recommendations (like ENISA and NIST) come down on a strong security margin for keys intended for use over the next decade.

The point that I appreciate in @AliceWonderMiscreations's argument is that the 2048-bit keys that we generate aren't individually intended for use over a period of a decade, but rather for use over a period of several months, when they're used to authenticate Diffie-Hellman negotiations. So, these recommendations may be considering a different security context in most cases. Conceivably, we should be more worried about the DH modulus in most threat models because it's the limiting parameter that directly affects the long-term security level.

I'll try to get some practical data about the frequency of use of FS ciphersuites and the impact of 2048 vs. 3072-bit keys on server performance.

Contributor

schoen commented Oct 16, 2018

Hi @dkg,

FS and non-FS is a separate issue. Yes, we should encourage FS ciphersuites, and both clients and servers should be disabling non-FS ciphersuites where they know it to be possible to do so. (TLS 1.3 has no non-FS ciphersuites left, yay!) That doesn't mean that we should ignore the importance of a strong cryptographic identity key, or that we should play one off against the other. Remember that a forged identity key makes it possible to MiTM even a FS connection.

In the default case, we currently only use an individual RSA subject key for 60 days (with the active MITM risk continuing for the 90-day lifetime of the certificate), and then switch to a different one. It seems like there's a considerable difference between "an attacker who can break the 2048-bit key in 90 days can perform an active attack" and "an attacker who can break the 2048-bit key at any time can recover plaintext of old sessions that it was involved in". The former is true and the latter is not true in the case of FS ciphersuites.

The recommendations about keylength typically seem to assume a threat model in which the attacker breaks a key some time after that key is used—for example the recommendations that you mention below appear to be based on a threat model in which an attacker takes years to break an individual key. With FS ciphersuites, that threat model shouldn't be that relevant for deciding the length of the identity key because a given identity key has long since ceased to be used.

RSA 3072 appears to be the sweet spot where recommendations (like ENISA and NIST) come down on a strong security margin for keys intended for use over the next decade.

The point that I appreciate in @AliceWonderMiscreations's argument is that the 2048-bit keys that we generate aren't individually intended for use over a period of a decade, but rather for use over a period of several months, when they're used to authenticate Diffie-Hellman negotiations. So, these recommendations may be considering a different security context in most cases. Conceivably, we should be more worried about the DH modulus in most threat models because it's the limiting parameter that directly affects the long-term security level.

I'll try to get some practical data about the frequency of use of FS ciphersuites and the impact of 2048 vs. 3072-bit keys on server performance.

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