Hi,
I recently noticed that several packages in Fedora create RSA keys with inappropriate key sizes:
dnssec-trigger creates RSA 1536 keys with certificate that is valid for 20 years: https://bugzilla.redhat.com/show_bug.cgi?id=1045689
dropbear-keygen creates by default RSA 1024 keys: https://bugzilla.redhat.com/show_bug.cgi?id=1039311
Some other observations: ssh-keygen on F19 creates RSA 2048 keys by default
ENISA recommends to at least RSA 3072 keys: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable...
If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage.
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. I did not notice RSA keys with more than 4096 bits regularly, therefore I am not sure whether using RSA 15360 keys by default is a good idea.
What is your opinion?
Regards Till
On Sat, Dec 21, 2013 at 9:38 AM, Till Maas opensource@till.name wrote:
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default.
Such guidelines would be very desirable. The following needs to be addressed:
* Do we have the expertise to define the requirements? We could just follow the ENISA report or http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf , but each such publication has a risk of carrying an agenda. (Note that choosing the algorithms is just as important as choosing the key sizes.)
* Do we have the expertise to follow the requirements? The package maintainers would have to understand the source code to a much deeper extent than we've typically required. (I do think such a change in expectations would be a very good thing.)
* Can we actually get this done? Uses of MD5 and DES are probably a bigger threat, and I'm afraid we haven't made that much progress on eradicating them, over many years. Mirek
I'm willing to change, being as a maintainer of dropbear.
But I don't know the standard is encouraged only in EU or USA, also can expert's opinion represent all requirements?
Thanks. On Jan 3, 2014 12:53 AM, "Miloslav Trmač" mitr@volny.cz wrote:
On Sat, Dec 21, 2013 at 9:38 AM, Till Maas opensource@till.name wrote:
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default.
Such guidelines would be very desirable. The following needs to be addressed:
- Do we have the expertise to define the requirements? We could just
follow the ENISA report or http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf , but each such publication has a risk of carrying an agenda. (Note that choosing the algorithms is just as important as choosing the key sizes.)
- Do we have the expertise to follow the requirements? The package
maintainers would have to understand the source code to a much deeper extent than we've typically required. (I do think such a change in expectations would be a very good thing.)
- Can we actually get this done? Uses of MD5 and DES are probably a
bigger threat, and I'm afraid we haven't made that much progress on eradicating them, over many years. Mirek -- security mailing list security@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
On Thu, Jan 2, 2014 at 6:13 PM, Christopher Meng cickumqt@gmail.com wrote:
I'm willing to change, being as a maintainer of dropbear.
But I don't know the standard is encouraged only in EU or USA, also can expert's opinion represent all requirements?
Look at the table on top of page 22 of the ENISA report: it relates sizes of RSA keys and symmetrical (e.g. AES) keys. Where opinions differ, is 1) the strength comparisons (contents of the table), and 2) how much cryptographic strength is needed for a particular application.
The consensus for 1) is fairly stronger (based on published attacks). 2) is obviously somewhat "political", and a matter of opinion.
1) is sufficient to argue that a larger RSA key would improve the security of dropbear: If it is using AES-128, it is still getting only around "80 bits of security" with the smaller RSA key. OTOH, 2) is still an issue - you need to decide whether the longer connection time is acceptable in the '"embedded"-type Linux systems' the package description mentions Mirek
On Thu, Jan 02, 2014 at 05:47:34PM +0100, Miloslav Trmač wrote:
On Sat, Dec 21, 2013 at 9:38 AM, Till Maas opensource@till.name wrote:
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default.
Such guidelines would be very desirable. The following needs to be addressed:
- Do we have the expertise to define the requirements? We could just
follow the ENISA report or http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf , but each such publication has a risk of carrying an agenda. (Note that choosing the algorithms is just as important as choosing the key sizes.)
At least with minimal key sizes no harm can be done as long as no package uses shorter minimal keys sizes because of this. Also for algorithms I think it is a good idea to ban certain bad algorithms by default but allow for packages to support stronger variants by default it upstream decided so. But if one upstream decides it, there might be a good reason to make it default for Fedora.
- Do we have the expertise to follow the requirements? The package
maintainers would have to understand the source code to a much deeper extent than we've typically required. (I do think such a change in expectations would be a very good thing.)
At least for default key sizes it should be only a constant that needs to be changed as long as the software itself supports bigger keys. But I would solve this when problems appear.
- Can we actually get this done? Uses of MD5 and DES are probably a
bigger threat, and I'm afraid we haven't made that much progress on eradicating them, over many years.
Changing algorithms is a lot harder than changing minimal key sizes. But it is moving on.
Regards Till
----- Original Message -----
From: "Till Maas" opensource@till.name
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. I did not notice RSA keys with more than 4096 bits regularly, therefore I am not sure whether using RSA 15360 keys by default is a good idea.
Yes, everybody agrees that 1024 bit RSA keys are too small for any long term usage.
From what I see, the disagreement between NISA, CA/B Forum and ENISA stems
from the security margins they consider safe.
If you compare NIST and ENISA standards at 128 bit security level, you'll see that both of them recommend 3072 bit RSA keys (and 256 bit ECDSA keys). NIST just considers 112 bit security (the level which 3DES provides) still good enough (up to year 2030), and that's why they consider 2048bit RSA keys to be OK.
See Table 2 in NIST SP 800-57 and table 3.6 in ENISA report for comparison.
using 15360 RSA keys be default is definitely not a good idea, not only they are very large and as such introduce big delays in TLS negotiation, but also signing or verifying such big signatures is very slow (think 0.5s for creation of a single signature on an 3GHz Core i7 and many seconds on a smartphone)
On Sat, 21 Dec 2013, Till Maas wrote:
ENISA recommends to at least RSA 3072 keys: [...] If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage.
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. [...]
I know I am very late but let me add a comment: according to ENISA, "near-term" means "at least 10 years" and "long-term" means "30 to 50 years". (*)
I do not think a particular SSH, TLS or similar key--at least unless it is stored in a HSM (**)--should be used for 10 or more years, therefore it is somewhat questionable how and to what extent ENISA recommendations are relevant. 3072 or even 4096 might be worth considering for keys whose expected lifetime is long because they need to stay the same (such as CA keys) or because they are used to encrypt and store sensitive data but any other key should be recycled, let's say, at least once in every 3 years (***).
YMMV.
(*) The jump from 128 bits to 256 bits between ENISA "near-term" and "long-term", that is over the course of 20-40 years, is somewhat puzzling to me. It means they expect the strength of crypto to drop by a factor of 2^3 to 2^7 per year on average.
I have done a small survey of crypto cracking devices (it turns out the publicly available information is quite sparse):
Year___Machine________________Tech___Speed_____Price___Speed/Cost____ 1998 EFF DES Cracker ASIC 90 G/s $210 k 0.4 M/s/$ 2006 COPACOBANA FPGA 35 G/s $13 k 2.7 M/s/$ 2014 ButteflyLabs 600 GH ASIC 1000 G/s ? $2.2 k 450 M/s/$ ?
Gotchas: Prices are not inflation-adjusted and do no include anything but hardware. COPACOBANA is FPGA based, an equivalent ASIC implementation could have had perhaps an order of magnitude better speed/cost ratio. ButteflyLabs is a bitcoin mining device expected to compute 600 G/s of bitcoin hashes, the corresponding DES cracking speed is my wild guess; and the device itself might be a kind of vapourware, given the reputation its maker has earned...
It seems to me there has been 10^3 or perhaps 10^4-fold improvement in available computing power (measured in bang per buck) over the last 16 years--1 bit/year at best. And this is the improvement for symmetric crypto cracking that is a perfect job for loosely coupled hardware.
On the other hand, factorization with NFS needs (as far as I know) to solve a humongous system of linear equations and that task scales much worse and requires a tightly coupled machine with adequately humongous shared memory. We're talking about terabytes for 1024-bit numbers and tens of petabytes of RAM or more for 2048-bit numbers!
But who knows? Maybe they are hedging against possible cryptoanalytic/number theoretic breakthroughs. Or maybe they take into consideration something I have overlooked.
(**) Let us assume, for a moment, that we do not live in a world where an average HSM imposes a hard limit on the length of RSA keys and the limit had often been already too low when the device was manufactured.
(***) If long-term secrecy is desired for data transmitted using a transport protocol (TLS, SSH), one should rely on perfect forward secrecy provided by the use of ephemeral (EC)DH keys rather than on a server private key staying confidential for a long time (not broken and not leaked or stolen). Unfortunately, the support of ephemeral DH in many programs is, ahem, questionable...
On Sun, 2014-03-30 at 14:43 +0200, Pavel Kankovsky wrote:
On Sat, 21 Dec 2013, Till Maas wrote:
ENISA recommends to at least RSA 3072 keys: [...] If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage.
Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. [...]
I know I am very late but let me add a comment: according to ENISA, "near-term" means "at least 10 years" and "long-term" means "30 to 50 years". (*)
I do not think a particular SSH, TLS or similar key--at least unless it is stored in a HSM (**)--should be used for 10 or more years, therefore it is somewhat questionable how and to what extent ENISA recommendations are relevant.
I don't understand what do you mean using SSH and TLS for 10 or more years, but we have an expectation of secrecy of data for 10 or more years. When you do a TLS or SSH session you don't expect that your transferred data will be leaked within a few months or a year later.
regards, Nikos
On Mon, 31 Mar 2014, Nikos Mavrogiannopoulos wrote:
I don't understand what do you mean using SSH and TLS for 10 or more years, but we have an expectation of secrecy of data for 10 or more years. When you do a TLS or SSH session you don't expect that your transferred data will be leaked within a few months or a year later.
Let me repeat one of my footnotes:
(***) If long-term secrecy is desired for data transmitted using a transport protocol (TLS, SSH), one should rely on perfect forward secrecy provided by the use of ephemeral (EC)DH keys rather than on a server private key staying confidential for a long time (not broken and not leaked or stolen). Unfortunately, the support of ephemeral DH in many programs is, ahem, questionable...
On Mon, 2014-03-31 at 22:34 +0200, Pavel Kankovsky wrote:
On Mon, 31 Mar 2014, Nikos Mavrogiannopoulos wrote:
I don't understand what do you mean using SSH and TLS for 10 or more years, but we have an expectation of secrecy of data for 10 or more years. When you do a TLS or SSH session you don't expect that your transferred data will be leaked within a few months or a year later.
Let me repeat one of my footnotes: (***) If long-term secrecy is desired for data transmitted using a transport protocol (TLS, SSH), one should rely on perfect forward secrecy provided by the use of ephemeral (EC)DH keys rather than on a server private key staying confidential for a long time (not broken and not leaked or stolen). Unfortunately, the support of ephemeral DH in many programs is, ahem, questionable...
This is wrong as you present it. You cannot substitute forward secrecy as a replacement for good parameters. A 512-bit DHE key exchange provides forward secrecy but does not provide secrecy. I can break it and decrypt all data. In all cases you need parameters that reflect the security level required, whether in forward or non-forward secrecy.
regards, Nikos
----- Original Message -----
From: "Pavel Kankovsky" peak@argo.troja.mff.cuni.cz To: "Nikos Mavrogiannopoulos" nmav@redhat.com Cc: security@lists.fedoraproject.org Sent: Monday, 31 March, 2014 10:34:37 PM Subject: Re: Crypto guidelines for Fedora
On Mon, 31 Mar 2014, Nikos Mavrogiannopoulos wrote:
I don't understand what do you mean using SSH and TLS for 10 or more years, but we have an expectation of secrecy of data for 10 or more years. When you do a TLS or SSH session you don't expect that your transferred data will be leaked within a few months or a year later.
Let me repeat one of my footnotes:
(***) If long-term secrecy is desired for data transmitted using a transport protocol (TLS, SSH), one should rely on perfect forward secrecy provided by the use of ephemeral (EC)DH keys rather than on a server private key staying confidential for a long time (not broken and not leaked or stolen). Unfortunately, the support of ephemeral DH in many programs is, ahem, questionable...
The ENISA recommendations are generic, not everybody uses ECDHE or DHE key exchange. Either because, as you point out, the support is not there, or because they use client cipher selection and most of the clients are Windows machines or because the administrator disabled all DH suites because he or she fears for performance problems caused by DHE and doesn't know that this does not apply for ECDHE suites.
Also, cryptosystems that don't use primitives of comparable strength are rather frowned upon (if only because security assessment of such systems is more complex).
On Tue, 1 Apr 2014, Nikos Mavrogiannopoulos wrote:
This is wrong as you present it. You cannot substitute forward secrecy as a replacement for good parameters.
I did not intend to say anything like that and I am sorry if my choice of words was unfortunate enough to make such impression.
Much of the discussion dealt with RSA keys and their lengths. My point was that at a certain point it would become more efficient to invest man-hours and CPU cycles into stronger ephemeral DH (ECDH if possible) rather than into stronger server RSA keys.
A 512-bit DHE key exchange provides forward secrecy but does not provide secrecy.
This is an interesting example of the difference between "dictum simpliciter" and "dictum secundum quid". :)
On Tue, 1 Apr 2014, Hubert Kario wrote:
The ENISA recommendations are generic, not everybody uses ECDHE or DHE key exchange.
Indeed, the DH key exchange is optional when you use SSL/TLS. On the other hand, it is mandatory for IPsec or SSH (v2).
Also, cryptosystems that don't use primitives of comparable strength are rather frowned upon (if only because security assessment of such systems is more complex).
If we took that seriously, most TLS servers using 128+-bit symmetric keys should be frowned upon because their certification chains include RSA keys shorter than 3072 bits.
And even if the chain were strong enough, the whole TLS PKI would be only as strong as its weakest link and it is likely their clients trust root CA keys that are only 1024 bits long (C=US, O=Equifax, OU=Equifax Secure Certificate Authority and C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root to name two examples from tls-ca-bundle.pem in F20).
(This situation is, to be honest, ridiculous. Everything is completely upside-down. When you got a hierarchy of cryptographic keys, a key at its top should better be the strongest of all of them because if it were cracked the whole hierarchy would be compromised.)
----- Original Message -----
From: "Pavel Kankovsky" peak@argo.troja.mff.cuni.cz To: security@lists.fedoraproject.org Sent: Thursday, 3 April, 2014 1:13:44 AM Subject: Re: Crypto guidelines for Fedora
On Tue, 1 Apr 2014, Hubert Kario wrote:
Also, cryptosystems that don't use primitives of comparable strength are rather frowned upon (if only because security assessment of such systems is more complex).
If we took that seriously, most TLS servers using 128+-bit symmetric keys should be frowned upon because their certification chains include RSA keys shorter than 3072 bits.
Yes, they don't provide 128 bit secrecy in case where they don't use PFS cipher suite with proper parameters, and provide less than 128 bit authentication in case where they do.
It is acceptable because we don't have 80 bit ciphers and 112 bit ciphers (3DES) are slower than everything else on every platform. So we use 128bit+ ciphers.
That doesn't change the fact that most of web is running with effective security of 80 bit and just now some of it is migrating to 112 bit security.
(This situation is, to be honest, ridiculous. Everything is completely upside-down.
Yes, yes it is.
When you got a hierarchy of cryptographic keys, a key at its top should better be the strongest of all of them because if it were cracked the whole hierarchy would be compromised.)
The problem is that we have to deal with a lot of hysterical^W historical reasons. Clients that don't support SHA-2, clients that can work with just 1024bit RSA, clients that didn't update their CA trust store for the past 10 years, etc.
There's no way to fix it so we have to workaround it.
security@lists.fedoraproject.org
-
Christopher Meng -
Hubert Kario -
Miloslav Trmač -
Nikos Mavrogiannopoulos -
Pavel Kankovsky -
Till Maas