[PATCH] Adding diversity for security

[Stephen Crane]

I would love to use a different off-the-shelf RNG (crypto++ is certainly 
an option). It's simply a matter of choosing what to link against. I 
simply went for the most convenient and widespread crypto lib I could 
think of. However, since threading is being problematic (since LLVM 
doesn't "do" threading currently, we don't to my knowledge have a 
locking function to set up), maybe we should use a different, perhaps 
less common, lib which is thread-safe.

I'll see if I can whip up a crypto++ RNG interface which might make this 
easier. We will still need the fallback RNG to compile without the 
library available.

- stephen

On 10/02/13 13:12, 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.