<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 24, 2014 at 7:32 PM, David Leon Gil <span dir="ltr"><<a href="mailto:coruus@gmail.com" target="_blank">coruus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Fri, Oct 24, 2014 at 5:01 PM, Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:<br>
> On Fri, Oct 24, 2014 at 1:56 PM, Bear <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> wrote:<br>
>> On Fri, 2014-10-24 at 05:31 -0400, Bill Cox wrote:<br>
>> > So, why do we need true random data at high speed so badly that Intel<br>
>> > decided to build in a device requiring large capacitors and it's own<br>
>> > power regulator?  The truth is, we don't need high speed.  As many<br>
>> > people have argued here, all any single system requires is 256 bits of<br>
>> > true random data.  That's all they *ever* need, so long as it remains<br>
>> > secret (which is hard), and so long as a cryptographically secure PRNG<br>
>> > (CPRNG) is used to generate all future cryptographically pseudo-random<br>
>> > data (which is comparatively easy).<br>
<br>
</span>The current provable-security bounds on recovering from state<br>
compromise require anywhere from 2KiB to 20 KiB of input entropy to<br>
recover from "state compromise". See section 5.3 of<br>
<a href="http://www.cs.nyu.edu/~dodis/ps/prematureNext.pdf" target="_blank">http://www.cs.nyu.edu/~dodis/ps/prematureNext.pdf</a><br>
<br>
So, perhaps some applications would want a fairly large amount of entropy.<br>
</blockquote></div><br></div><div class="gmail_extra">Interesting paper.  Here's how I would recover much faster.<br><br>I write 512 bits containing over 400 bits of entropy in one call, as the minimum, with ioctl.  I have to look at the kernel code to see how it works, but assuming:<br><br></div><div class="gmail_extra">1) The kernel sucks in all 512 bits at once, blocking all other users of /dev/random and /dev/urandom, and then performs a secure cryptographic one-way hash on it's entire entropy pool.<br></div><div class="gmail_extra">2) The cryptographic hash is ideal in the sense that it's output cannot be distinguished from true random, and cannot be reversed short of brute force guessing all 2^n input possibilities.<br></div><div class="gmail_extra">3) No attacker can guess a state of the pool when no state has higher than a 1/2^256 probability<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Under these assumptions, the pool recovers from a state compromise in one call.  The pool is not full, but no state has a probability higher than about 1/2^400 so it does not matter.<br><br></div><div class="gmail_extra">However, I just went and looked a bit at random.c.  I would have to look a *lot* harder to feel confident I am reading it right, but at first glance, it's mixing function, _mix_pool_bytes does not satisfy my assumptions above.  It does not appear to be a cryptographically secure hash function.  It simply stirs data in the pool weakly, counting on lots of entropy data to make that OK. <br><br>This seems insecure to me, but I suppose there are probably reasons for 
the Linux kernel to weakly mix the input entropy rather than performing a
 secure hash.  If I were writing that code, I'd turn Blake2b into a 
sponge (similar to Lyra2), and would only mix in entropy once I'd collected at least 256 bits worth.  That way, the state becomes secure again on every update.<br><br></div><div class="gmail_extra">Can I use a simple hack to insure the Linux entropy is secure after every write to /dev/random?  I am thinking of force-feeding it 4096 bits from the Keccac sponge, rather than just 512 bits like I do now.  Is my reading of random.c's mixing accurate?  Will this hack insure that the entropy pool is securely refreshed?<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br></div><div class="gmail_extra">Given that they write the entropy pool to disk on shutdown, instant recovery from state compromise seems like an important goal.<br><br></div><div class="gmail_extra">Bill<br></div></div>