Bug ID: JDK-6708214 java.security.SecureRandom.nextBytes() takes a long time.

Type: Bug
Component: security-libs
Sub-Component: java.security
Affected Version: 5.0u11

Priority: P2
Status: Closed
Resolution: Duplicate
OS: linux
CPU: x86

Submitted: 2008-05-28
Updated: 2010-05-10
Resolved: 2008-05-30

FULL PRODUCT VERSION :
1.5.0_11-b03

ADDITIONAL OS VERSION INFORMATION :
Red Hat Linux version 5(RHEL5)

A DESCRIPTION OF THE PROBLEM :
When we run our java based tool on RHEL5 is taking a long time to complete. After doing some investigation and debugging, found out that the SecureRandom methods (especially SecureRandom.nextBytes) were taking a long time(in the matter of seconds and even a minute at times) to complete.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A stand-alone program which uses SecureRandom.nextBytes should be able to reproduce the problem onm RHEL5.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The intended operation will take a while to complete. This performance is not acceptable. The performance should match with what we see on RHEL5.
ACTUAL -
The intended operation will take a while to complete.

REPRODUCIBILITY :
This bug can be reproduced often.

EVALUATION For more info on /dev/random vs. /dev/urandom: http://en.wikipedia.org/wiki//dev/random See workaround in 6202721 ("file:/dev/./urandom"). Be sure to note that /dev/urandom isn't as random as /dev/random. Mostly likely the problem is that there is not enough entropy in the linux /dev/random device. Even though it says "file:/dev/urandom" in the java.security file, this string is actually an alias for "file:/dev/random" in the Unix/Linux native SeedGeneration code. Unfortunate, we probably can't change for compatibility reasons. /dev/random will stall until there is random noise (keyboard input, mouse movement, etc.) /dev/urandom won't stall, and will make a best guess at some randomness.
30-05-2008
WORK AROUND Since they're running 5.0xXX, try the workaround found in 6202721
30-05-2008
EVALUATION The customer made a mistake when they logged the bug, they are not using 1.4.2 but 1.5.0 (1.5.0_11-b03).
29-05-2008
EVALUATION Since this is 1.4.2, can't they point to securerandom.source=file:/dev/urandom.
29-05-2008

Duplicate :	JDK-6202721 - SHA1PRNG reads from /dev/random even if /dev/urandom selected
Relates :	JDK-4705093 - Use /dev/urandom rather than /dev/random if it exists.
Relates :	JDK-5108581 - SecureRandom class unable to generate faster random nos on faster machines
Relates :	JDK-6521844 - SecureRandom hangs on Linux Systems