[PATCH] Adding diversity for security

[Stephen Crane]

It turns out that we cannot use the OpenSSL RNG directly, since it 
auto-seeds itself from system randomness, and we cannot make the seed 
deterministic. In addition, we cannot compile against Crypto++ since it 
requires RTTI to even include its headers.

Therefore, I've cleaned up the AES-based NIST SP 800-90A CTR_DRBG random 
number generator. It should now be entirely thread-safe, with a seperate 
RNG for each thread. I've also added comments describing the 
construction and some of the OpenSSL details. Please let me know what 
you think.

- Stephen

On 10/02/2013 01:12 PM, Tom Roeder wrote:
> I agree that the OpenSSL API is a little messy for setting up locks,
> but once you've worked your way through the details once, it's pretty
> easy to manage. From what I know about OpenSSL, I don't think it
> guarantees any thread safety at all for libcrypto unless you jump
> through the hoops of setting up the right locking structures. See the
> first line of the description section in
> http://www.openssl.org/docs/crypto/threads.html. Maybe there's another
> crypto library you can use that satisfies your constraints better and
> still saves you from having to write your own RNG? E.g., Crypto++?
>
> >From a purely software-engineering perspective, it seems to me that a
> compiler framework is the wrong place to have a cryptographically
> secure implementation of a pseudo-random generator. But that's a
> policy decision, and I'm new to the LLVM community, so others are more
> qualified than me to answer this question.
>
> If you're going to stick with the AES-based implementation, I would
> echo Alex's comment: I would like to see more justification in the
> comments. Putting on my applied crypto hat, I would like to see
> comments that contain an abstract specification of the protocol, along
> with a justification for its security. For example, this could be
> satisfied with a reference to a paper that proves this protocol to be
> a secure implementation of a PRG.