<div dir="ltr">Gary,<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 6, 2017 at 4:48 PM Gary E. Miller <<a href="mailto:gem@rellim.com">gem@rellim.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br class="gmail_msg">
Unless you believe, as many do, that RDRAND is backdoored.<br class="gmail_msg">
<br class="gmail_msg">
FeeBSD refuses to use RDRAND:<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/" rel="noreferrer" class="gmail_msg" target="_blank">http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/</a><br class="gmail_msg">
<br class="gmail_msg">
OTOH, The Exalted Head Penguin prefers to jsut add it into a bigger mix:<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_nsa_gchq/" rel="noreferrer" class="gmail_msg" target="_blank">http://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_nsa_gchq/</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Both Linux and FreeBSD use RDRAND as input to /dev/urandom. They just differ in how they do so. Linux mixes it in directly using XOR (a poor, but not necessarily disastrous idea, depending on your threat-model) and FreeBSD mixes it in after passing it through Yarrow.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br class="gmail_msg">> FreeBSD does<br class="gmail_msg">
> the correct thing with blocking early on.<br class="gmail_msg">
<br class="gmail_msg">
And available to us in recent Python, but NTPsec is stuck supporting 2.6.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>My read of the documentation is that in FreeBSD sys_getrandom() and /dev/urandom are essentially identical. It is in Linux where they differ (with early blocking of entropy). I definitely like the idea of switching to sys_getrandom() if available.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > Can we add entropy to the pool?<br class="gmail_msg">
> On systems with /dev/urandom, you can write data to it and it will<br class="gmail_msg">
> be  mixed into the entropy pool. Other systems may have other ways of<br class="gmail_msg">
> accomplishing this.<br class="gmail_msg">
<br class="gmail_msg">
Which misses the point, how do get the entopy to add to the pool?<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Well, there aren't many ways. It would take a lot of work, but that it how we would add it if we had it. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > Can we postprocess the urandom entropy to get more entropy?<br class="gmail_msg">
> There are post-processing steps which can be taken which will reduce<br class="gmail_msg">
> the risks associated with certain problems.<br class="gmail_msg">
<br class="gmail_msg">
Security by obscurity.  Not a good idea.  Only adding entropy helps.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Not at all. Lack of entropy is not the only issue with RNGs. For example, the notorious DUAL_EC_DRBG did not have a problem with entropy. Its problem was that it leaked state to people who knew a certain secret.  FreeBSD is (once again) an excellent example of doing things properly. They do not use the output of RDRAND directly but rather use it to seed and reseed another PRNG (Yarrow) and then use the outputs of Yarrow. This is a very safe way of using RDRAND. So, if we really felt it worthwhile (and we shouldn't) we could implement another trustworthy RNG (such as Yarrow, Fortuna, AES_CTR_DRBG, HMAC_DRBG, etc.) and pass the input through there. This is almost always a bad idea as we really don't want to be maintaining cryptographic code like that. I call it out simply as an example of ways in which you can take problematic (and possibly backdoored) data and safely use it.</div><div><br></div><div>Greg</div></div></div>