<p dir="ltr">I bypassed rngd and write directly to /dev/random. One very cool thing about the modular noise multiplier is the very accurate estimate of the entropy I am adding.  Basically anyone using /dev/urandom effectively is mounting a denial of service attack against people who need true random data.  Also the entropy mixing code has a problem in that it takes tiny amounts of entropy in at a time, enabling certain attacks. Because of these weaknesses I feel it is reasonable for some people to bypass the system entropy pool, but this is also asking for trouble. I do not know why this code is not modernized.</p>
<p dir="ltr">Bill</p>
<div class="gmail_quote">On Dec 20, 2014 4:52 AM, "Jim Cheetham" <<a href="mailto:jim@gonzul.net">jim@gonzul.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A couple of days ago I received this message from Thomas Hühn <<a href="mailto:t@2uo.de">t@2uo.de</a>> :-<br>
<br>
> Hi Jim,<br>
><br>
> On <a href="http://onerng.info/random.html" target="_blank">http://onerng.info/random.html</a> you claim that "This interface internally does exactly the same as /dev/random, except that when the entropy pool is close to exhaustion it will instead start to deliver data from a software device, a PRNG that has been seeded from 'good' random data.".<br>
><br>
> That's wrong. The _only_ difference between /dev/random and /dev/urandom on Linux is that the latter doesn't care about the amount of estimated entropy in the pool(s).<br>
><br>
> The output of /dev/random is hashed and processed in exactly the same way as the output of /dev/urandom, there is no PRNG exclusive to the latter.<br>
><br>
> You can find more details in <a href="http://www.2uo.de/myths-about-urandom/#structure" target="_blank">http://www.2uo.de/myths-about-urandom/#structure</a><br>
<br>
I've done a fair bit of reading based on that link of his, and of<br>
course it opens up some more questions. I certainly used to assume<br>
that /dev/random's source of data was different to /dev/urandom's, and<br>
a quick read through random.c does indeed back up Thomas' description<br>
that they are indeed the same.<br>
<br>
However, given that, I don't yet understand how re-seeding is affected<br>
by the entropy collector processes, I'm a little confused about<br>
initial seeding and how that relates to key generation, and I'm really<br>
stuck as to what the entropy estimate counter is trying to achieve.<br>
<br>
None of this directly affects OneRNG and its goals; it does mean that<br>
the default benefit to a Linux system needs more consideration, and I<br>
have to tighten up some of the text I've written on the website & put<br>
into presentations.<br>
<br>
I'd appreciate some other people having a look at this article and<br>
giving me their comments :-)<br>
<br>
-jim<br>
<br>
--<br>
<br>
View topic <a href="http://lists.onerng.info/r/topic/1Y0BjLuZzH3giPaU8oz948" target="_blank">http://lists.onerng.info/r/topic/1Y0BjLuZzH3giPaU8oz948</a><br>
<br>
Leave group mailto:<a href="mailto:onerng-talk@lists.onerng.info">onerng-talk@lists.onerng.info</a>?Subject=unsubscribe<br>
<br>
Start groups <a href="http://OnlineGroups.net" target="_blank">http://OnlineGroups.net</a><br>
</blockquote></div>