<div dir="ltr"><div>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 (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html</a>), as well as the patch discussions (<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130930/189585.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130930/189585.html</a>) 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.<br>
<br></div>- stephen<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 10:48 AM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> > Also, at the very least, adding the RNG should be split out<br>
> > into a separate patch.<br>
> ><br>
<br>
</div>Amen to that, brother.<br>
<div class="im"><br>
> ><br>
> > Why? We usually land supporting facilities together with the first<br>
> > use for ease of review and testing.<br>
<br>
</div>Sometimes. Other times they're done independently. Depends on the<br>
size and complexity of the pieces.<br>
<div class="im"><br>
> ><br>
> ><br>
> > Especially for integrating with foreign code, we do separate patches<br>
> > (even sometimes separate discussions on llvmdev), consult e.g. the<br>
> > additions of MD5 and zlib.<br>
><br>
> The RNG in the patch is a small class with LLVM's existing MD5<br>
> implementation being the only dependency.<br>
<br>
</div>But the choice of MD5 for this purpose is inherently suspect.<br>
<br>
My own security days are over a decade behind me but it's not hard<br>
to find serious objections to using a hash function as the core of<br>
a PRNG. F'rinstance [1] goes into some detail, once you get past<br>
the list of objections to the original post/question on that thread.<br>
I haven't found any published statistical analysis of an MD5-based<br>
RNG to put the nails in the coffin but I am persuaded that it's not<br>
such a great idea. It is _specifically_ _not_ a crypto-level RNG.<br>
<br>
Most of the motivation to use MD5 in this mode seems to boil down<br>
to the obviously flawed syllogism:<br>
(a) MD5 was invented by a crypto guru<br>
(b) crypto == good<br>
(c) therefore MD5 == good for purposes other than what it was<br>
designed for<br>
This is a general critique, lots of people (who aren't crypto or<br>
security trained) tend to think this way, as evidenced by the<br>
number of MD5-based RNGs you can find on the web.<br>
--paulr<br>
<br>
[1] <a href="http://security.stackexchange.com/questions/21277/create-a-variants-of-md5" target="_blank">http://security.stackexchange.com/questions/21277/create-a-variants-of-md5</a><br>
<br>
P.S. I'm not taking a position on the value of the NOP feature, just<br>
mouthing off about the RNG piece of it.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>