| |||||||||||||
True randomnessTrue randomnessPosted Mar 30, 2012 17:09 UTC (Fri) by man_ls (subscriber, #15091)In reply to: True randomness by alankila Parent article: Russell: Sources of Randomness for Userspace See, the problem about randomness (and probably why you perceive my message as cryptic and foreboding) is that it can only be defined in the negative. The complete absence of patterns is basically impossible to prove; it can only be suspected. But I see you like your solutions simple and your answers straight. Your hypothesis is easy to test: $ cat /dev/randomand see how quickly it fills out. For me it is barely enough to reseed urandom (32 bytes) once a minute, while using it; if I leave it alone it seems to take quite longer. As to practical attacks against /dev/urandom: I hope that there are none because then I fear all my communications (and most in the world) would be vulnerable. But perhaps the NSA (or other sinister organizations) have a few of their own.
(Log in to post comments)
True randomness Posted Mar 31, 2012 16:47 UTC (Sat) by alankila (subscriber, #47141) [Link]
I just tested this. It seems that entropy collection takes very long time indeed. What a pity. Apparently there's just a kernel buffer that contains gathered entropy, and consuming that entropy allows me to see that it will be replenished rather slowly. So the statistic munin graphs me is not the rate of entropy generation, but merely the amount of available entropy.
Somehow this multi-gigahertz multi-core machine and all its myriad peripherals together are not harvested for more entropy than about 10 bits per second.
True randomness Posted Mar 31, 2012 16:52 UTC (Sat) by man_ls (subscriber, #15091) [Link] Right, that is where haveged should help. Whether it works well in virtualized machines remains to be seen.
|
|||||||||||||