2:38 a.m.
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/delivera...
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
10:47 a.m.
On Sat, Dec 21, 2013 at 9:38 AM, Till Maas <opensource(a)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
11:13 a.m.
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(a)volny.cz> wrote:
On Sat, Dec 21, 2013 at 9:38 AM, Till Maas
<opensource(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security
11:42 a.m.
On Thu, Jan 2, 2014 at 6:13 PM, Christopher Meng <cickumqt(a)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
2:21 p.m.
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(a)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
6:14 a.m.
----- Original Message -----
From: "Till Maas" <opensource(a)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)
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
http://wiki.brq.redhat.com/hkario
Email: hkario(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
7:43 a.m.
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...
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
3 a.m.
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
3:34 p.m.
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...
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
3:11 a.m.
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
5:10 a.m.
----- Original Message -----
From: "Pavel Kankovsky"
<peak(a)argo.troja.mff.cuni.cz>
To: "Nikos Mavrogiannopoulos" <nmav(a)redhat.com>
Cc: security(a)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).
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hkario(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
6:13 p.m.
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.)
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
7:06 a.m.
----- Original Message -----
From: "Pavel Kankovsky"
<peak(a)argo.troja.mff.cuni.cz>
To: security(a)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.
--
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
3675
days inactive
3778
days old
security@lists.fedoraproject.org
12 comments
6 participants
participants (6)
-
Christopher Meng -
Hubert Kario -
Miloslav Trmač -
Nikos Mavrogiannopoulos -
Pavel Kankovsky -
Till Maas