Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Oct 2015 14:49:55 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Prime example of a can of worms

On Mon, Oct 19, 2015 at 1:34 PM, Seth Arnold <seth.arnold@...onical.com>
wrote:
>
>
> Should there be any middle-ground for how much use a specific value gets?
> Part of the weakdh gift is the reconition that randomly generated 1024 bit
> primes might be fine for one router or website to use but is terrible when
> used by millions and might repay the cost to crack it.
>

I would say applying similar rules as encryption, e.g. strong encryption
for file encryption and weaker crypto may be ok for e.g. session data.
Where those dials get set is currently anyones guess (since we have no real
public data to support decisions strongly).


>
> Do we allow 1024-bit dhparams when they are randomly generated? Or do we
> also want to move these to e.g. 2048 out of abundance of caution?
>
> (I don't share Kurt's pessimism on generating DH primes, though that does
> come with the caveat that they should only be generated on systems that
> have been running long enough to collect enough entropy for random number
> generation to work well.)
>
> Thanks
>

It's not as easy as that. Assuming people follow
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf and get it
correct (and optionally certified) then yes it is "not hard" but one thing
that continues to worry me:

We have AFAIK no good test suites to ensure random numbers/primes are
cryptographically secure.

If we did we wouldn't have issues like CVE-2008-0166.


--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com

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