Crypto guidelines for Fedora

[Pavel Kankovsky]

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 /