On Fri, Aug 12, 2016 at 9:31 PM, Christopher Schultz <chris@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 8/11/16 11:10 PM, Marat Khalili wrote: >> From what I saw, this behavior of /dev/random is totally normal on >> an idle Linux system. > > There seems to be some confusion about /dev/random on Linux systems. > Yes, the behavior described here is normal: when the system comes up, > there is very little entropy available on /dev/random. /dev/random > needs random events to occur in order to provide that entropy, and > those events are things like I/O interrupt timings, etc. There is quickly not enough entropy when using /dev/random, and very few (if any) interest in using it. > > IIRC, Linux relies on the keyboard to generate lots of those events > and, on a server, the keyboard by definition doesn't get used. So > other events are required to fill that entropy pool. So, after a > reboot, the entropy pool is "shallow". This is true after booting, but also each time /dev/random is (ab)used. On the other hand, there is /dev/urandom, requiring 128bits of entropy to be initialized (which are always there after the boot, except maybe for specific embedded devices with no disk, hardly servers), plus a few more entroy from time to (long) time, and is just as secure as /dev/random (often the same implementation, certainly on Linux), while never waiting/blocking for entropy... > > /dev/random is supposed to be a source of high-quality randomness > /dev/urandom is supposed to be a source of low-quality randomness This isn't true. > >> Just do not ever use /dev/random. +1 > > The choice of which to use is up to you, but remember that low-quality > randomness gets you low-quality crypto keys. But to say that one > should "not ever use /dev/random" is really bad advice. If you really want to block and exhaust all entropy for the (few) needs of /dev/urandom users, well you can use it, otherwise don't. Regards, Yann. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx