[Ach] Bug/Ba in OpenSSL

ianG iang at iang.org
Tue Jan 7 09:56:18 CET 2014

On 25/11/13 20:15 PM, Aaron Zauner wrote:

>> 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
> http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/

I'm curious -- where is BSAFE used?  As far as I was aware, it was 
mostly shipped to USG. Is it in general shipping with in any user field? 
  You mention “high security” proprietary windows and java applications 
... but are those things we should be worried about if we don't use 
them?  Any clue as to which they are?

Yes, this is off topic to ACH :)

>> 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.

I need a pithy statement for this.

> Dan Kaminsky has proposed an universal RNG a couple of times now - but again, this is not to be used in production.
> See section 2: 'Four Lines of Javascript that Can’t Possibly Work So why do they?'
> http://openwall.info/wiki/_media/people/solar/pocorgtfo01.pdf

:)  So, that works as a quickie.  But it is also quite easy to attack, 
if that is the only thing going on.  RNGs are not easy on software 


More information about the Ach mailing list