Discarding data to /dev/random instead of /dev/null

I just happened across this article, recommending that discardable output be redirected to /dev/random instead of just thrown into /dev/null https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/ Looks interesting - keen to hear other thoughts. Eric -------------------------------------------- Q: Why is this email five sentences or less? A: http://five.sentenc.es

On Fri, 20 Mar 2015 13:18:12 +1300, Eric Light wrote:
I just happened across this article, recommending that discardable output be redirected to /dev/random instead of just thrown into /dev/null
https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/
Looks interesting - keen to hear other thoughts.
Well, it can’t hurt...

I wrote:
On Fri, 20 Mar 2015 13:18:12 +1300, Eric Light wrote:
I just happened across this article, recommending that discardable output be redirected to /dev/random instead of just thrown into /dev/null
https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/
Looks interesting - keen to hear other thoughts.
Well, it can’t hurt...
However, note this from the random(4) man page: Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

Eric Light wrote:
I just happened across this article, recommending that discardable output be redirected to /dev/random instead of just thrown into /dev/null
https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/
Looks interesting - keen to hear other thoughts.
Call me paranoid, but doing this by convention would seem vulnerable to attacks that load up /dev/random with known data (or that act on predictions of what a system would write to it). That wouldn't result in easily predictable results from the CSPRNG, but it would lower the entropy and that's surely bad. butting

On Fri, 20 Mar 2015 14:20:17 +1300, Bryce Utting wrote:
Call me paranoid, but doing this by convention would seem vulnerable to attacks that load up /dev/random with known data (or that act on predictions of what a system would write to it). That wouldn't result in easily predictable results from the CSPRNG, but it would lower the entropy and that's surely bad.
No it wouldn’t. Or rather, it would only matter on a system where nothing else was contributing to /dev/random. Which would mean you’re in trouble, anyway. Remember, the whole point of hashing is that the least little bit change from whatever source makes the output look quite different. Or, to put it another way, feeding predictable data contributes zero entropy, but it cannot take away from the entropy already there.

I just happened across this article, recommending that discardable output be redirected to /dev/random instead of just thrown into /dev/null
https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/ <https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/>
Looks interesting - keen to hear other thoughts.
Stirring up your CSPRNG cannot hurt. Bandwidth seems to be a possible bottleneck, but if you’re just redirecting somewhat noisy scripts, it’s not going to cause a problem. On a related note, it’s well worth reading “Myths about /dev/urandom” (http://www.2uo.de/myths-about-urandom/ <http://www.2uo.de/myths-about-urandom/> ) as well as the pages it references. Linux’s use of the blocking-when-entropy-is-low /dev/random is somewhat confusing, and at times very frustrating - and for the vast majority of use cases, completely unnecessary. ( I raise this only because the quoted article above still suggests that you need to keep the “entropy pool topped off at full”, which is perpetuating the myth)

https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/ <https://pthree.org/2014/12/07/use-dev-random-instead-of-dev-null/>
On a related note, it’s well worth reading “Myths about /dev/urandom” (http://www.2uo.de/myths-about-urandom/ <http://www.2uo.de/myths-about-urandom/> ) as well as the pages it references. Linux’s use of the blocking-when-entropy-is-low /dev/random is somewhat confusing, and at times very frustrating - and for the vast majority of use cases, completely unnecessary.
( I raise this only because the quoted article above still suggests that you need to keep the “entropy pool topped off at full”, which is perpetuating the myth)
And amusingly, Aaron Toponce (who owns pthree.org <http://pthree.org/> above) was the author of the other great article I read on how people misunderstand /dev/urandom: https://pthree.org/2014/07/21/the-linux-random-number-generator/ <https://pthree.org/2014/07/21/the-linux-random-number-generator/>. Also worth a read. (And yet,) he still suggests that “topping off” /dev/random is something you need to do ! )
participants (4)
-
Bryce Utting
-
Daniel Lawson
-
Eric Light
-
Lawrence D'Oliveiro