Reading Entropy_Avail File Appears to Consume Entropy

Reading entropy_avail file appears to consume entropy

Found an answer in here http://blog.flameeyes.eu/2011/03/entropy-broken

Starting a process consumes entropy

Will python SystemRandom / os.urandom always have enough entropy for good crypto

There's a subtle difference between the output of /dev/random and /dev/urandom. As has been pointed out, /dev/urandom doesn't block. That's because it gets its output from a pseudo-random number generator, seeded from the 'real' random numbers in /dev/random.

The output of /dev/urandom will almost always be sufficiently random -- it's a high-quality PRNG with a random seed. If you really need a better source of random data, you could consider getting a system with a hardware random number generator -- my netbook has a VIA C7 in it, which can generate quite a lot of properly random data (I get a consistent 99.9kb/s out of /dev/random, 545kb/s out of /dev/urandom).

As an aside, if you're generating passwords then you might want to look at pwgen -- it makes nice pronounceable passwords for you :).

java slow : entropy related issue

This is actually a hack introduced into the JVM back in 1.3 or 1.4 days

http://bugs.sun.com/view_bug.do?bug_id=4705093

http://bugs.sun.com/view_bug.do?bug_id=6202721

The basic issue is that in the native JVM code they hardcoded /dev/urandom to actually use /dev/random to attempt to ensure sufficient entropy. Since /dev/urandom is supposed to be guaranteed not to block, this has the unintended consequence of blocking if not enough entropy is available.

The hardcoding looks specifically for the string /dev/urandom, so providing something that resolves to the same thing but doesn't match that causes the desired behavior. If you code /dev/./urandom you bypass the hardcoded aliasing and get to the intended urandom entropy source.

How to fill kernel entropy without X and hardware RNG?

Take a data stream from your camera, hash it using something decent like BLAKE2b or SHA2, then feed it into /dev/random.

Once the entropy count is >=256 you are good to go.

From then only read from /dev/urandom/.

/dev/urandom will happily spew out cryptographically secure pseudorandom data suitable for key material once the system has 256 bits of entropy available.

Running out of entropy after you've collected this amount is a myth. Use /dev/urandom, really, it's perfectly fine.

Determine if /dev/random slows down processes

Read the random(4) man page. It mentions reading sequentially
/proc/sys/kernel/random/entropy_avail (a read-only textual pseudo file); see proc(5) for details about /proc/ pseudo-file-system.

You could just read /dev/urandom BTW which won't block (but might be "less" random).

BTW, you might perhaps poll(2) the fd for /dev/random before reading it (if you want to avoid being blocked, or use fcntl(2) for non blocking mode with O_NONBLOCK etc...).

See also kernel's hw_random.txt

NB: notice that some other process might read /dev/random too...

---

Related Topics