[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1453373025.3030.24.camel@trustmatta.com>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
