[PATCH] Adding diversity for security

[Tom Roeder]

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.

On Wed, Oct 2, 2013 at 11:14 AM, Stephen Crane <sjcrane at uci.edu> wrote:
> Looking into this a bit further, it seems that the OpenSSL RNG is not
> thread-safe (without locks, which the API for is rather messy). As such, it
> is probably better to initialize one RNG per thread, which rand.h does not
> support. Therefore, I'd recommend keeping the existing thread-local
> AES-based RNG...
>
> - stephen
>
>
> On 10/02/13 10:28, Tom Roeder wrote:
>>
>> >From what I've seen, it's been quite stable. Looking back in the git
>> logs of openssl, it looks like the last time a change touched rand.h
>> was in 2011, and that was just to add FIPS stuff. Then the last change
>> before then was in 2009. So, I would say it's safe to rely on it.
>>
>>
>>
>> On Wed, Oct 2, 2013 at 10:19 AM, Stephen Crane <sjcrane at uci.edu> wrote:
>>>
>>> Tom,
>>>
>>> You make a very good point which I never actually considered. I confess
>>> that
>>> I am not very familiar with the OpenSS APIL and was simply looking for a
>>> drop-in replacement for our existing simple AES implementation, which had
>>> a
>>> conflicting open-source license. Looking at the the OpenSSL RNG now, I
>>> see
>>> no problems with it as long as it is stable between versions.
>>>
>>> - Stephen
>>>
>