RE: ENTROPY EXHAUSTION IN JAVA FIPS

Hello,

Not going much into the entropy discussion let=92s just say you are not run=
ning out of entropy but you are hitting the Linux kernels entropy predictio=
n limit.

It might be a work around, but recent Linux distributions (sles and Ubuntu =
offer haveged out of the box and recent EL have rngd in the Repo) have entr=
opy replenishing D=E4mons for the entropy source challenged servers (both u=
sing cpu jitter as the most common source and can use a hwrng if present)

In my experience this avoids blocking /dev/random

Gruss
Bernd

--
http://www.seeburger.com
________________________________________
From: Lothar Kimmeringer [[email protected]]
Sent: Wednesday, October 30, 2019 11:26
To: [email protected]
Subject: Re: [dev-crypto] 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=92ve been doing a bunch of performance testing with a code base that I=
=92m attached
> to and I=92ve noticed that using the BC fips security provider my code ex=
hausts
> 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









SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael =
Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Fe=DFenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SE=
EBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial =
Register:
e-mail: [email protected]               HRB 240708 Mannheim


Dieses E-Mail ist nur f=FCr den Empf=E4nger bestimmt, an den es gerichtet i=
st und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material=
 enthalten. Jegliche darin enthaltene Ansicht oder Meinungs=E4u=DFerung ist=
 die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung =
der SEEBURGER AG dar. Sind Sie nicht der Empf=E4nger, so haben Sie diese E-=
Mail irrt=FCmlich erhalten und jegliche Verwendung, Ver=F6ffentlichung, Wei=
terleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens un=
tersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) =FCber=
nehmen die Haftung f=FCr Viren; es obliegt Ihrer Verantwortung, die E-Mail =
und deren Anh=E4nge auf Viren zu pr=FCfen.


This email is intended only for the recipient(s) to whom it is addressed. T=
his email may contain confidential material that may be protected by profes=
sional secrecy. Any fact or opinion contained, or expression of the materia=
l herein, does not necessarily reflect that of SEEBURGER AG. If you are not=
 the addressee or if you have received this email in error, any use, public=
ation or distribution including forwarding, copying or printing is strictly=
 prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept=
 liability for viruses; it is your responsibility to check this email and i=
ts attachments for viruses.