JDK-8058455 : Use random/urandom instead of C_GenerateRandom
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.security
  • Affected Version: 7u51
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris
  • CPU: sparc
  • Submitted: 2014-09-15
  • Updated: 2015-12-04
  • Resolved: 2015-12-04
Related Reports
Duplicate :  
JDK-8098581 - SecureRandom.nextBytes() hurts performance with small size requests
Description
Going through C_GenerateRandom to get random numbers is 
heavy-weight and has the side-effect of bringing in PKCS#11 
unnecessarily and impacting performance. 

Either open /dev/random or /dev/urandom and read random 
numbers from that, or call random_get_bytes or 
random_get_bytes in S12.0.  

When java.util.UUID.randomUUID is called, java.security.SecureRandom 
uses PKCS#11 to get random numbers with C_GenerateRandom.  This was 
discovered by an exception thrown from an Apache app written for an 
internal project. 

07/01/2014 16:06:50.550 UTC idx22 ERROR Failed to index 
PSARC/1994/128/IAM.UI_user-level_MT_interfaces 
java.security.ProviderException: nextBytes() failed 
at sun.security.pkcs11.P11SecureRandom.implNextBytes(P11SecureRandom.java:186) 
at sun.security.pkcs11.P11SecureRandom.engineNextBytes(P11SecureRandom.java:135) 
at java.security.SecureRandom.nextBytes(SecureRandom.java:455) 
at java.util.UUID.randomUUID(UUID.java:145)
Comments
Tony's work in JDK-8098581 means this is no longer an issue. SecureRandom has been added to the pkcs11 exclude cfg list. We should backport that to 8u and perhaps 7u
04-12-2015
We should avoid any C_GenerateRandom PKCS11 call when on Solaris IMO. Be default, Sun-PKCS11 is the preferred SecureRandom provider. Can we just open /dev/random and read bytes from there instead? P11SecureRandom.implNextBytes(byte[]) could have this change. We need to be careful if on linux though where reading /dev/random can have more noticeable performance issues.
16-10-2014
IIRC, UUID uses the most preferred SecureRandom provider, which would mean adding SecureRandom to the list of disabled providers on Solaris. In that case, NativePRNG (which is non-blocking for nextBytes() and blocking for generateSeed()) is the default impl.
17-09-2014
In JDK 8, we added NativePRNGBlocking and NativePRNGNonBlocking SecureRandom implementations which read from /dev/random and dev/urandom (respectively) on Unix platforms. It might be worth investigating using these instead of (or in preference to) PKCS11 as there would be less (or none?) JNI overhead. Also, if you use the new method SecureRandom.getInstanceStrong() it will return NativePRNGBlocking by default on Unix platforms.
17-09-2014