United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6708214 java.security.SecureRandom.nextBytes() takes a long time.
6708214 : java.security.SecureRandom.nextBytes() takes a long time.

Details
Type:
Bug
Submit Date:
2008-05-28
Status:
Closed
Updated Date:
2010-05-10
Project Name:
JDK
Resolved Date:
2008-05-30
Component:
security-libs
OS:
linux
Sub-Component:
java.security
CPU:
x86
Priority:
P2
Resolution:
Duplicate
Affected Versions:
5.0u11
Fixed Versions:

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

Sub Tasks

Description
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.

Comments
WORK AROUND

Since they're running 5.0xXX, try the workaround found in 6202721
2008-05-30 
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.
2008-05-30 
EVALUATION

Since this is 1.4.2, can't they point to securerandom.source=file:/dev/urandom.
2008-05-29 
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).
2008-05-29


Hardware and Software, Engineered to Work Together