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
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
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 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

EVALUATION Since this is 1.4.2, can't they point to securerandom.source=file:/dev/urandom.
2008-05-29