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 [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ