<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>ryuuchin</author><text>The solution (currently sans kernel patching) is to just seed &amp;#x2F;dev&amp;#x2F;urandom yourself at system startup to avoid the issue of it not being seeded.  Don&amp;#x27;t most distro&amp;#x27;s do this anyway?&lt;p&gt;After that it&amp;#x27;s just down to using &amp;#x2F;dev&amp;#x2F;urandom[1] or the getrandom syscall (which is the same as using &amp;#x2F;dev&amp;#x2F;urandom).  Also the getrandom syscall actually has the behavior you&amp;#x27;re talking about.&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;sockpuppet.org&amp;#x2F;blog&amp;#x2F;2014&amp;#x2F;02&amp;#x2F;25&amp;#x2F;safely-generate-random-numbers&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;sockpuppet.org&amp;#x2F;blog&amp;#x2F;2014&amp;#x2F;02&amp;#x2F;25&amp;#x2F;safely-generate-random...&lt;/a&gt;</text><parent_chain><item><author>aidenn0</author><text>Has anybody made a set of patches to give linux the BSD behavior (block until seeded, then never block again)?  I run into issues with &amp;#x2F;dev&amp;#x2F;random regularly and while I can patch every single application, that feels like playing whack-a-mole compared to patching the kernel.</text></item><item><author>tptacek</author><text>This proposed design comprehensively ratifies Linux&amp;#x27;s nonsensical legacy random&amp;#x2F;urandom division; for instance, it maintains a &amp;quot;512 bit emergency entropy level&amp;quot; in case urandom becomes &amp;quot;stressed&amp;quot;. It appears to be motivated principally by concerns about the quality of entropy being fed continually into the LRNG --- which is a nonproblem.&lt;p&gt;This is silly.&lt;p&gt;There are three problems a kernel CSPRNG needs to address:&lt;p&gt;1. It needs to seed itself reliably and not provide output when it&amp;#x27;s not securely seeded.&lt;p&gt;2. It needs to re-key itself regularly to provide forward secrecy and recovery from attacks.&lt;p&gt;3. It needs to be performant enough to be used in applications to the exclusion of all other RNGs.&lt;p&gt;That&amp;#x27;s it. Once problem (1) is addressed, there is never again for the uptime of the system a concern about the quality or &amp;quot;level&amp;quot; of entropy in the LRNG. DRBGs like this document proposes are effectively stream ciphers (in fact: Salsa20, the new hotness in bulk cipher designs, is essentially a hash DRBG --- and, in the BSDs, a [crappy] stream cipher &lt;i&gt;was&lt;/i&gt; the RNG). &amp;quot;Entropy&amp;quot; keys the cipher. The idea that you can &amp;quot;run low&amp;quot; on entropy is the same as the idea that you can &amp;quot;run low&amp;quot; on key. No.&lt;p&gt;Kernel CSPRNGs do need continually updated entropy pools. But not because their original entropy is depleted! Rather: you want your RNG to be updated so that its &amp;quot;key&amp;quot; changes regularly, so that if your system is compromised transiently, you&amp;#x27;ll recover.&lt;p&gt;And, of course, the division between &amp;#x2F;dev&amp;#x2F;random and &amp;#x2F;dev&amp;#x2F;urandom sabotages goal (3) --- arguably the most important goal. Almost every time you&amp;#x27;ve read about some crypto randomness catastrophe --- from Debian commenting out their RNG and reducing SSH key space to 16 bits, to Bitcoin wallets coughing up private keys by repeating nonces --- you&amp;#x27;ve been reading about &lt;i&gt;userspace RNG failures&lt;/i&gt;. People use userspace RNGs because they think the kernel RNG is too slow. And they think the kernel RNG is too slow because they use &amp;#x2F;dev&amp;#x2F;random, which obstinately refuses to provide output when --- wait, I&amp;#x27;m not dignifying &amp;#x2F;dev&amp;#x2F;random: it refuses to provide output &lt;i&gt;at random&lt;/i&gt;.</text></item></parent_chain></comment><story><title>/dev/random – a new approach</title><url>http://lwn.net/Articles/684568/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>nshepperd</author><text>If you&amp;#x27;re using udev, you can configure it to make &amp;#x2F;dev&amp;#x2F;random a symlink to &amp;#x2F;dev&amp;#x2F;urandom (eg. [1]). Sadly that doesn&amp;#x27;t give you the &amp;quot;block until seeded&amp;quot; behaviour though, and I don&amp;#x27;t know of any kernel patch doing that yet.&lt;p&gt;1. &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;superuser.com&amp;#x2F;questions&amp;#x2F;309840&amp;#x2F;how-can-i-point-dev-random-to-dev-urandom&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;superuser.com&amp;#x2F;questions&amp;#x2F;309840&amp;#x2F;how-can-i-point-dev-ra...&lt;/a&gt;</text><parent_chain><item><author>aidenn0</author><text>Has anybody made a set of patches to give linux the BSD behavior (block until seeded, then never block again)?  I run into issues with &amp;#x2F;dev&amp;#x2F;random regularly and while I can patch every single application, that feels like playing whack-a-mole compared to patching the kernel.</text></item><item><author>tptacek</author><text>This proposed design comprehensively ratifies Linux&amp;#x27;s nonsensical legacy random&amp;#x2F;urandom division; for instance, it maintains a &amp;quot;512 bit emergency entropy level&amp;quot; in case urandom becomes &amp;quot;stressed&amp;quot;. It appears to be motivated principally by concerns about the quality of entropy being fed continually into the LRNG --- which is a nonproblem.&lt;p&gt;This is silly.&lt;p&gt;There are three problems a kernel CSPRNG needs to address:&lt;p&gt;1. It needs to seed itself reliably and not provide output when it&amp;#x27;s not securely seeded.&lt;p&gt;2. It needs to re-key itself regularly to provide forward secrecy and recovery from attacks.&lt;p&gt;3. It needs to be performant enough to be used in applications to the exclusion of all other RNGs.&lt;p&gt;That&amp;#x27;s it. Once problem (1) is addressed, there is never again for the uptime of the system a concern about the quality or &amp;quot;level&amp;quot; of entropy in the LRNG. DRBGs like this document proposes are effectively stream ciphers (in fact: Salsa20, the new hotness in bulk cipher designs, is essentially a hash DRBG --- and, in the BSDs, a [crappy] stream cipher &lt;i&gt;was&lt;/i&gt; the RNG). &amp;quot;Entropy&amp;quot; keys the cipher. The idea that you can &amp;quot;run low&amp;quot; on entropy is the same as the idea that you can &amp;quot;run low&amp;quot; on key. No.&lt;p&gt;Kernel CSPRNGs do need continually updated entropy pools. But not because their original entropy is depleted! Rather: you want your RNG to be updated so that its &amp;quot;key&amp;quot; changes regularly, so that if your system is compromised transiently, you&amp;#x27;ll recover.&lt;p&gt;And, of course, the division between &amp;#x2F;dev&amp;#x2F;random and &amp;#x2F;dev&amp;#x2F;urandom sabotages goal (3) --- arguably the most important goal. Almost every time you&amp;#x27;ve read about some crypto randomness catastrophe --- from Debian commenting out their RNG and reducing SSH key space to 16 bits, to Bitcoin wallets coughing up private keys by repeating nonces --- you&amp;#x27;ve been reading about &lt;i&gt;userspace RNG failures&lt;/i&gt;. People use userspace RNGs because they think the kernel RNG is too slow. And they think the kernel RNG is too slow because they use &amp;#x2F;dev&amp;#x2F;random, which obstinately refuses to provide output when --- wait, I&amp;#x27;m not dignifying &amp;#x2F;dev&amp;#x2F;random: it refuses to provide output &lt;i&gt;at random&lt;/i&gt;.</text></item></parent_chain></comment><story><title>/dev/random – a new approach</title><url>http://lwn.net/Articles/684568/</url></story>