[PATCH] Adding diversity for security

[Robinson, Paul]

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

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.