<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 19, 2013, at 12:04 PM, Stephan Mueller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Am Donnerstag, 19. Dezember 2013, 07:56:36 schrieb Arnold Reinhold:<br><br>Hi Arnold,<br><br><br><blockquote type="cite">How do we safely initialize Yarrow or a another software RNG if the<br></blockquote><blockquote type="cite">CPU's hardware RNG is compromised and there is no other source of<br></blockquote><blockquote type="cite">entropy? This is a situation that is increasingly common in all<br></blockquote><blockquote type="cite">solid-state black box devices, and is especially tricky at first<br></blockquote><blockquote type="cite">startup, when keys used to manage such units are often generated.<br></blockquote><br>There are various implementations of RNGs that use CPU execution timing <br>variations as noise source. That phenomenon is available right from the <br>start of the CPU. In fact, the patch in my Jitter RNG [4] for the Linux <br>/dev/random would fill the input_pool with entropy during initialization <br>at system boot time, early in the boot cycle. This could be done for a <br>Yarrow as well. I guess the other RNGs could be used in a similar <br>fashion.<br><br>So, there are noise sources which do not depend on some black box.<br><br>[1] <a href="http://www.issihosts.com/haveged/">http://www.issihosts.com/haveged/</a><br>[2] <a href="http://dankaminsky.com/2012/08/15/dakarand/">http://dankaminsky.com/2012/08/15/dakarand/</a><br>[3] <a href="http://jytter.blogspot.se/">http://jytter.blogspot.se/</a><br>[4] <a href="http://www.chronox.de/">http://www.chronox.de/</a><br><br><br>Ciao<br>Stephan<br></div></blockquote></div><br><div>Sandy Harris mentioned one more: <a href="ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/">ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/</a></div><div><br></div><div>I am not able to evaluate these RNG schemes that rely on uncertainties in CPU timing. They may well provide a solution, but I am not prepared to bet that people who can modify CPU innards, can't find a way to defeat them. In section 2.1 of your <a href="http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html">http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html</a> you point out some possibilities, but say that if an attacker has that much access to the CPU, they have other means of compromising your system. That may not be true. The beauty of a compromised CPU RNG is that it does not require any covert communication from the compromised system back to the attacker. </div><div><br></div><div>As others have said, a billion chip CPU is impossible to audit. Adding what I proposed, a key stretcher in the initialization chain of an OS RNG like Yarrow or /dev/random, is very simple to do and need only add a few seconds to first boot up. The best solution however is still an auditable source of randomness independent of the CPU.</div><div><br></div><div><br></div><div>Arnold Reinhold</div></body></html>