ENTROPY EXHAUSTION IN JAVA FIPS

classic Classic list List threaded Threaded
6 messages Options
Jon
Reply | Threaded
Open this post in threaded view
|

ENTROPY EXHAUSTION IN JAVA FIPS

Jon
Hi all,

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.
Ex.
cat /proc/sys/kernel/random/entropy_avail
Shows values under 10 while my code it running.

When I use the system default security provider the available number never drops below 3000. I mention the cpu arch because I’ve also tried this on a Skylake machine and I do not see the entropy exhaustion there and I believe that’s down to intel providing hardware random number generation on Broadwell and later.

I’m adding BC as my default provider via
Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
Pretty much at the entry point to my program. So, my question is; am I simply misconfiguring something here? I saw a bug around this in the release notes here
https://www.bouncycastle.org/fips-java/RELEASE_NOTES.md
Is this a known issue for 1.0.2 as well?
The current known issues list is blank
https://www.bouncycastle.org/fips-java/BC-FJA-KnownIssues-1.0.2.csv

Thanks,
Jon
Reply | Threaded
Open this post in threaded view
|

Re: ENTROPY EXHAUSTION IN JAVA FIPS

David Hook-3

See section 2.3 of

https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf

Regards,

David

On 30/10/19 11:16 am, Jon Moroney wrote:

> Hi all,
>
> 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.
> Ex.
> cat /proc/sys/kernel/random/entropy_avail
> Shows values under 10 while my code it running.
>
> When I use the system default security provider the available number never drops below 3000. I mention the cpu arch because I’ve also tried this on a Skylake machine and I do not see the entropy exhaustion there and I believe that’s down to intel providing hardware random number generation on Broadwell and later.
>
> I’m adding BC as my default provider via
> Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
> Pretty much at the entry point to my program. So, my question is; am I simply misconfiguring something here? I saw a bug around this in the release notes here
> https://www.bouncycastle.org/fips-java/RELEASE_NOTES.md
> Is this a known issue for 1.0.2 as well?
> The current known issues list is blank
> https://www.bouncycastle.org/fips-java/BC-FJA-KnownIssues-1.0.2.csv
>
> Thanks,
> Jon
>


Reply | Threaded
Open this post in threaded view
|

Re: ENTROPY EXHAUSTION IN JAVA FIPS

Lothar Kimmeringer-4
In reply to this post by Jon
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

Reply | Threaded
Open this post in threaded view
|

RE: ENTROPY EXHAUSTION IN JAVA FIPS

Eckenfels. Bernd
Hello,

Not going much into the entropy discussion let’s just say you are not running out of entropy but you are hitting the Linux kernels entropy prediction 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 entropy replenishing Dämons for the entropy source challenged servers (both using 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 [[hidden email]]
Sent: Wednesday, October 30, 2019 11:26
To: [hidden email]
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’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









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


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material 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, publication 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 its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|

Re: ENTROPY EXHAUSTION IN JAVA FIPS

Lothar Kimmeringer-4
Hi,

Am 30.10.2019 um 11:41 schrieb Eckenfels. Bernd:

> It might be a work around, [using haveged or rng-tools]
>
> In my experience this avoids blocking /dev/random

It helps for a local system but if you provide a software you expect
customers to install on their own systems it's a bad start for a
discussion if the reason is that a mission critical production system
stopped working due to a blocked /dev/random.

Using haveged as a work around for a blocking /dev/random is
esentially admitting that the randomness of /dev/random and
/dev/urandom are of the same quality and that it's enough for
your needs (which I state is the case for >99.9% of current
uses of BouncyCastle "out there"). Same for rng-tools without
some random number generator available to it.


Cheers, Lothar

Reply | Threaded
Open this post in threaded view
|

AW: [dev-crypto] ENTROPY EXHAUSTION IN JAVA FIPS

Eckenfels. Bernd
Lothar, that might have been true in the past (especially where the daemons only fed /dev/urandom into /dev/random). However both daemons do (meanwhile) more than that (i.e. sampling CPU jitter or mixing in hwrandom). For this reason ist not only a "unblocking" but also really increasing unpredictablitiy oft he kernel random state.

However it does not hurt do do all 3, use bybrid, use /dev/unrandom and run the rng daemons.

(side note: even if you only feed dev/urandom into the entropy pool it would increase unpredictability since linux XORs all urandom reads with RDRAND which should be available on most CPUs).

Gruss
Bernd
-----Ursprüngliche Nachricht-----
Von: Lothar Kimmeringer <[hidden email]>
Gesendet: Mittwoch, 30. Oktober 2019 12:37
An: [hidden email]
Betreff: Re: [dev-crypto] ENTROPY EXHAUSTION IN JAVA FIPS

Hi,

Am 30.10.2019 um 11:41 schrieb Eckenfels. Bernd:

> It might be a work around, [using haveged or rng-tools]
>
> In my experience this avoids blocking /dev/random

It helps for a local system but if you provide a software you expect customers to install on their own systems it's a bad start for a discussion if the reason is that a mission critical production system stopped working due to a blocked /dev/random.

Using haveged as a work around for a blocking /dev/random is esentially admitting that the randomness of /dev/random and /dev/urandom are of the same quality and that it's enough for your needs (which I state is the case for >99.9% of current uses of BouncyCastle "out there"). Same for rng-tools without some random number generator available to it.


Cheers, Lothar









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


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material 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, publication 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 its attachments for viruses.