Re: ENTROPY EXHAUSTION IN JAVA FIPS

Hi,

Trigger warning: this might sound like a rant and in a way it is.

Am 30.10.2019 um 01:16 schrieb Jon Moroney:

> I’ve been doing a bunch of performance testing with a code base that I’m attached
> to and I’ve noticed that using the BC fips security provider my code exhausts
> the entropy available on my intel haswell linux machines.
> This is using the 1.0.2 version of the library.

"Running out of entropy" is a term best described as BS. A nice read
about this is https://www.2uo.de/myths-about-urandom

> Ex.
> cat /proc/sys/kernel/random/entropy_avail
> Shows values under 10 while my code it running.

That information alone is not very helpful. What version of Linux, is it
a headless system, etc. Much of the "entropy" Linux-systems generate
from user interactions like key strokes and mouse movements. That's
why I e.g. avoid using SecureRandom.getInstanceStrong because that uses
/dev/random and more often than once brought my application to a stillstand
due to entropy that "ran out" and /dev/random blocking a read.

Most use cases can happily work with a "drained entropy pool". If you
have a different one you already have to ensure that your randomness
is really random and should use HRNGs or even TRNGs. Using that should
keep your entropy-meter in the green all the time.


Cheers, Lothar