Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jan 2016 11:43:45 +0100
From: Florent Daigniere <florent.daigniere@...stmatta.com>
To: oss-security@...ts.openwall.com
Subject: Re: Prime example of a can of worms

On Thu, 2016-01-21 at 04:05 +0300, gremlin@...mlin.ru wrote:
> On 2016-01-20 08:45:07 -0700, Kurt Seifried wrote:
> 
>  > I finally got the article written and published, it's at:
>  > https://securityblog.redhat.com/2016/01/20/primes-parameters-and-m
> oduli/
> 
> In that article you wrote:
> 
>  > I think the best plan for dealing with this in the short term
>  > is deploying larger primes (2048 bits minimum, ideally 4096
>  > bits) right now wherever possible.
> 
> 4096 bit keys seem to be the absolute minimum, and personally I've
> already moved to 8192 bit keys.
> 

I'd like to know where you guys picked those numbers from:
http://www.keylength.com/en/compare/ suggests that 2048 bits is okay
for everyone but the BSI (at least not past 2016). Surely a
recommendation today should have a higher standard than that.

On the other hand, 3072 bits seems to be enough for everyone for the
next decade or so.

I haven't found anyone suggesting that bigger groups are either
necessary or worth it. If you want QC proof crypto you need groups of
~16k bits.

My favourite recommendation (ECRYPT II):
http://www.keylength.com/en/3/
where
1024 bits -> level 3 (<<2015)
2048 bits -> level 5 (2020)
3248 bits -> level 7 (2040)
for any of the modelled adversaries.

> Here are some numbers:
> 
> `openssl dhparam -2 4096` took 1:53:29 to generate (HH:MM:SS);
> `openssl dhparam -5 4096` took 1:43:44;
> `openssl dhparam -2 8192` took 25:51:34;
> `openssl dhparam -5 8192` took 16:51:47.
> 
>  > Why not huge primes?
>  > Why not simply use really large primes? Because computation
>  > is expensive, battery life matters more than ever and latency
>  > will become problems that users will not tolerate.
> 
> Any and all cryptographic transforms must be expensive - that means
> at least time and electric power. 

There is a good reason why no one wants custom-groups in protocol
design. I haven't seen it mentioned much so far so I will spell it out
again:

Custom groups need to be transmitted for each handshake: that's
problematic on most networks (none of the group sizes suggested will
fit on a MTU worth of data) as it will involve fragmentation and
potentially retransmission.

If anything, TLS has proven that it won't work; both because 
- no one will use the feature, even if it's present (status-quo with
1024 bits groups today)
- it's impractical for it to be used anywhere where the connectivity is
anything less than perfect (mobile networks, high-latency networks,
...)

K.I.S.S.!

Florent
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ