[Ach] Bug/Ba in OpenSSL
azet at azet.org
Mon Nov 25 18:15:40 CET 2013
On 25 Nov 2013, at 17:29, ianG <iang at iang.org> wrote:
> On 25/11/13 10:35 AM, Klaus Darilion wrote:
>> On 25.11.2013 04:36, Aaron Zauner wrote:
>>> I'm not aware of any projects or code that is using this random number
>>> generator of the FIPS module in OpenSSL. There is a lot of unused but
>>> still implemented code in OpenSSL. I might be wrong, if so please
>>> provide details.
>>> BTW. Matt Green wrote an insteresting blog post about this RNG:
>> Maybe it would be useful to add some words about random generators too.
>> E.g. practical advices to get good random generators and lots of entropy
>> if you need to generate lots of key materials (e.g. tools like entropy
>> tokens, haveged, ...)
> Typically, when it comes to RNGs, tools should use the default available, and mucking around with options isn't advisable.
> If we look at the problems we've had with RNGs, they've been mostly unfixable at the user level. From memory, early Java, Android, Debian.
> The counterpoint is DUAL_EC, as it was a default engineered by the NSA's finest, and recommended by RSA because "our technology is backed by highly regarded cryptographic experts." Unlike open source, they say :) So we could have fixed it, but only by going against the best advice available. Not really helpful as a strategy for the future, if you get my drift…
..then RSA had to recall BSAFE - a toolkit that is widely used in “high security” proprietary windows and java applications. oh noes!1
> In short: use it as it is setup, or write your own. There isn't a lot of middle ground.
I absolutely agree. RNGs that get shipped by operating systems are audited heavily, custom RNGs are not. As stated before: I haven’t found a analysis/research paper on HaveGE, the original paper describung the algorithm is years old. This does not seem to be well audited. Proof me wrong.
Dan Kaminsky has proposed an universal RNG a couple of times now - but again, this is not to be used in production.
> Ach mailing list
> Ach at lists.cert.at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Ach