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 / -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
