DEA /dev/random poor performance

[Mike Youngstrom]

I've noticed that occasionally when I deploy a tomcat app it takes a really long time for it to generate a secure random session id.  Here is an example log message:

Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [13,809] milliseconds.

I suspect what is happening is the /dev/random is getting too many requests for random numbers such that it doesn't have time to rebuild enough seed data.

Does anyone know if it is possible to speed up /dev/random to better support the kind of load a DEA hosting several might give it?  I know I could use /dev/urandom instead but I'd rather not use pseudo random numbers for crypto in my prod apps.

Thoughts?

Mike

[Filip Hanik]

if I was correctly informed, in the good old days, /dev/random was seeded with help of interrupts. so generating lots of interrupts improved the speed of it. such as finding files using mlocate could help speed it up.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDo7zSZpcd7wkQL3PNE_28DrQZ9%2BiZhO6MAicCfrrbHUOw%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Davanum Srinivas]

Mike,

Does this tip setting java.security.egd help?
https://wiki.apache.org/tomcat/HowTo/FasterStartUp#Entropy_Source

-- dims

> --
> You received this message because you are subscribed to the Google Groups
> "Cloud Foundry Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDo7zSZpcd7wkQL3PNE_28DrQZ9%2BiZhO6MAicCfrrbHUOw%40mail.gmail.com.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vcap-dev+u...@cloudfoundry.org.

--
Davanum Srinivas :: http://davanum.wordpress.com

[Mike Youngstrom]

Thanks Filip, interesting idea generating interrupts to increase secure random entropy.  I was hoping for a setting or something that could be set on the DEA.  I suppose I could start a process that just did a bunch of mlocates.

Thanks Davanum.  I'm aware of the /dev/urandom (pseudo random) trick but would prefer to use a secure random especially for other crypto apps may be doing.

Any other ideas?

Mike

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANw6fcEGmyOgUwWwP-1DSdaWFHG2i%3Dv8otQq9zU3aC0s_zaP6A%40mail.gmail.com.

[Mike Youngstrom]

Found some interesting info in the wikipedia article: http://en.wikipedia.org/wiki//dev/random

Perhaps I'll create a job that runs something to help improve the entropy pool like timer_entropyd.

Mike

[Alex Jackson]

You might also want to check out

http://www.2uo.de/myths-about-urandom/

and 

http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key

Both of which point out some FUD around /dev/urandom on Linux

Another contrasting opinion is 

https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

which says neither /dev/random or /dev/urandom are really safe to use for crypto.

Suffice to say there is a lot of uncertainty around this topic.

    - Alex.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDpxOfr7dn4fzHWQk594cUNGmwf62vs428zJcPeH5SMyyQ%40mail.gmail.com.

[Mike Youngstrom]

Thanks Alex.  Perhaps using /dev/urandom would work.

Another part of the equation is that I'm providing a platform to others apps and thirdparty apps.  I can recommend that people use /dev/urandom but any of my users who run into problems with /dev/random may not know about this recommendation.  All they may know is that their app is really slow or even failing when running on my platform.

I suppose another solution might be to remove /dev/random and link it to /dev/urandom at dea startup.  Either way I think I aught to do what I can to provide a good experience to those who are using /dev/random not just recommend people code/configure their apps to use /dev/urandom

Mike

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAN-TLMCaUJo_uCkkrmY-DDqA4W3EhU24DuESB0_jqBcZT%3DfEPg%40mail.gmail.com.

[sabh...@gmail.com]

I had to add the urandom option as part of the weblogic-buildpack to allow installation to proceed (as well as domain creation/server start).

But it appears to be fixed in Jdk8. Refer to: 

http://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html

http://openjdk.java.net/jeps/123 

-Sabha

[Mike Youngstrom]

That's interesting.  I actually ran into this issue with Java 8 and Tomcat 7.

Mike

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/eced0044-c1f4-490f-b2df-26a1f01aa35e%40cloudfoundry.org.

[sabh...@gmail.com]

Thanks, Mike. 

The doc talks of blocking and non-blocking generation - can it possibly involve using new code?

From the link:

Better Support for High Entropy Random Number Generation: The SecureRandom class provides the generation of cryptographically strong random numbers used for private or public keys, ciphers, signed messages, and so on. SomeSecureRandom implementations are better than others. The getInstanceStrong() method was introduced in JDK 8, which returns an instance of the strongest SecureRandom implementation available on each platform. It should be used in cases when you need to create a high-value and long-lived secret, such as an RSA private and public key pair.

For more information, see the SecureRandom section of the JCA Reference Guide and the SecureRandom API Specification.

Other changes to SecureRandom include:

• For UNIX-like platforms, two new implementations were introduced which provide blocking and non-blocking behavior: NativePRNGBlocking and NativePRNGNonBlocking.
• SHA1PRNG and NativePRNG were fixed to properly respect the SecureRandom seed source properties in the java.security file. (The obscure workaround using file:///dev/urandom and file:/dev/./urandom is no longer required.)

-Sabha

[James Bayer]

see below for some relevant interesting comments on this issue from apache developer mark thomas.

---------- Forwarded message ----------
From: Mark Thomas <mth...@pivotal.io>
Date: Mon, Aug 18, 2014 at 7:21 AM
Subject: Re: [vcap-dev] DEA /dev/random poor performance
To: James Bayer <jba...@pivotal.io>
Cc: Ryan Morgan <rmo...@pivotal.io>, Sabhanayakam Parameswaran <sparam...@pivotal.io>

Responses in-line

On Sat, Aug 16, 2014 at 1:53 PM, James Bayer <jba...@pivotal.io> wrote:

see below for some discussion here of a tomcat7 / jdk8 combination with poor performance due to the entropy issue for security init stuff. i'm not sure if tomcat developers hear about this complaint very often or not,

Not that often but often enough that it made it in the FAQ:
http://wiki.apache.org/tomcat/HowTo/FasterStartUp#Entropy_Source

 

but if there is an elegant way to use a new JDK8 feature in tomcat8 that provides a better user experience that is still considered secure,

Java 8 removes the need for the work-around so users are free to take advantage of that if they are running on Java 8..

I don't see the other Java 8 features being relevant here:

- getInstanceStrong() will either return the instance we already use or an even stronger (read slower) one. We don't need a stronger SecureRandom implementation (by default) - and we certainly don't want a slower one

- NativePRNGNonBlocking provides a neater way to use /dev/urandom and the hooks are already present in Tomcat for users to specify that specifically if they wish.

then that may be an interesting option to consider for tomcat. thinking about it makes me cringe a bit because i realize that would be introducing an alternate code path since jdk7 is supported tomcat8 [1]

There isn't anywhere in the Tomcat code base that comes to mind where we'd want to use any of these new features. I don't see us using getInstanceStrong(), the /dev/./urandom workaround happens outside the Tomcat code base so no changes are required there and users can use NativePRNGNonBlocking (or any other provider) now without any code changes required.

Some concerns have been raised about SHA1PRNG which Tomcat uses by default and, again, folks are free to switch to  a different impl and/or algorithm if they wish.

Mark

 

[1] http://tomcat.apache.org/whichversion.html

--

Thank you,

James Bayer

[Mike Youngstrom]

Thanks James.  I don't know why I'm still seeing this issue with Java 8 and Tomcat 7.  I'll take a closer look myself.

That said, after learning a little more about this subject I wonder if we might have a bigger issue here.  Servers by default generate very little entropy.  Even /dev/urandom requires some entropy to keep its non blocking random data from becoming deterministic.  Do we have a potential security issue here in multi-tenant systems?  For example, if I deploy a little app to a large number of DEAs then starve those systems of random data 'cat /dev/random' will I, as a resident app, get the same or deterministically similar /dev/urandom values as another app hosted on the same machine in another container?  Could I then use this data to subvert the cryptography any other app in the same deployment?

I still think it would be useful to have an entropy producing job that can be added to DEAs though probably not a big deal.

Mike

--

You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sUR94NUp14uEiT47F73Z4NQN3fJQcCrmC6FXXXEe0xZAA%40mail.gmail.com.

[lvyun]

Is this the same issue with this one[1]

[1] https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/GogAsIvBeVo？

在 2014年8月15日星期五UTC+8上午7时14分34秒，Mike Youngstrom写道：

[Mike Youngstrom]

Yup, sorry I didn't see that one. :)  Though this problem I think is a bit more broad it is the same initial problem.

Mike

--

You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/219ffbba-8168-4191-a1fc-1e373d750433%40cloudfoundry.org.