[PATCH] Adding diversity for security

[Alp Toker]

On 24/01/2014 18:48, Robinson, Paul wrote:
>>>          Also, at the very least, adding the RNG should be split out
>>>          into a separate patch.
>>>
> Amen to that, brother.
>
>>>      Why? We usually land supporting facilities together with the first
>>>      use for ease of review and testing.
> Sometimes.  Other times they're done independently.  Depends on the
> size and complexity of the pieces.
>
>>>
>>> Especially for integrating with foreign code, we do separate patches
>>> (even sometimes separate discussions on llvmdev), consult e.g. the
>>> additions of MD5 and zlib.
>> The RNG in the patch is a small class with LLVM's existing MD5
>> implementation being the only dependency.
> But the choice of MD5 for this purpose is inherently suspect.

I think there's value in having a callback mechanism to provide chunks 
of entropy, as a point to work on in-tree. There are a couple of 
features that would be able to make use of application-provided entropy 
and it'd fit well with LLVM's library design.

The application can then link into vendor-specific entropy or OpenSSL as 
needed if a higher grade of security is needed.

As a built-in default providing a reasonable level of reproducible 
unpredictability I'm satisfied with the use of existing MD5 facilities 
in LLVM. At some point we're probably going to want SHA1 for other 
purposes as well so that can happen when it's ready.

Alp.


>
> My own security days are over a decade behind me but it's not hard
> to find serious objections to using a hash function as the core of
> a PRNG.  F'rinstance [1] goes into some detail, once you get past
> the list of objections to the original post/question on that thread.
> I haven't found any published statistical analysis of an MD5-based
> RNG to put the nails in the coffin but I am persuaded that it's not
> such a great idea.  It is _specifically_ _not_ a crypto-level RNG.
>
> Most of the motivation to use MD5 in this mode seems to boil down
> to the obviously flawed syllogism:
> (a) MD5 was invented by a crypto guru
> (b) crypto == good
> (c) therefore MD5 == good for purposes other than what it was
>      designed for
> This is a general critique, lots of people (who aren't crypto or
> security trained) tend to think this way, as evidenced by the
> number of MD5-based RNGs you can find on the web.
> --paulr
>
> [1] http://security.stackexchange.com/questions/21277/create-a-variants-of-md5
>
> P.S. I'm not taking a position on the value of the NOP feature, just
> mouthing off about the RNG piece of it.
>
>

-- 
http://www.nuanti.com
the browser experts