Date: Thu, 21 Jan 2016 10:15:55 -0500 From: Steve Grubb <sgrubb@...hat.com> To: oss-security@...ts.openwall.com Cc: Florent Daigniere <florent.daigniere@...stmatta.com> Subject: Re: Prime example of a can of worms On Thursday, January 21, 2016 11:43:45 AM Florent Daigniere wrote: > 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 think that is assuming that quantum computers are not brought to market any time soon. Over the summer the NSA's Suite B page kind of backpeddled on the ECC requirements and refocused on RSA. I attended a speech this fall where NIST talked about what quantum computers will do. The presentation is here but does not have speakers notes: http://csrc.nist.gov/news_events/cif_2015/research/day1_research_200-250pt3.pdf This is the notes that I took while listening to the speech: This panelist talked about quantum crypto. The issue is that quantum computers could use Shor's algorithm and Grover's algorithm to kill PKI. In the future key sizes could be around a million bits. This will mean changes to network protocols. Its estimated that a key space of N can be search in the square root of N time. So, in current technology, if you need 128 bits of strength, you will need to square it to get the key size. Hallway discussions mentioned that ECC is dead due to trust issues and fuzzy IP issues which slowed vendor uptake. There was a mention of RSA officially being allowed to go to 16k key sizes. -Steve > 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