[PATCH] Adding diversity for security

[Stephen Crane]

We originally implemented the RNG as a implementation of the NIST SP
800-90A CTR_DRBG with AES as the block cipher, which is certainly a secure
(and fast) PRNG. However, at the time, there was strong push-back from the
LLVM community about adding a dependency on a 3rd party crypto library to
implement AES (I'm not implementing a production-quality fast AES
implementation, sorry). I'd point you to the original discussion thread on
llvmdev (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html),
as well as the patch discussions (
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130930/189585.html)
for more details on this switch. We decided that rather than try to force
an additional dependency on OpenSSL, we could switch to the HASH_DRBG RNG
with MD5. While probably less secure, this seems to be more practical at
the moment, especially since many are convinced that even using a secure
RNG is unnecessary in most use cases for diversity.

- stephen


On Fri, Jan 24, 2014 at 10:48 AM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> 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.
>
> 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.
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140124/979e6c90/attachment.html>