Update #2: JEP 123: SecureRandom First Draft and Implementation.

[Brad Wetmore]

Greetings,

Thanks so much for all of the constructive feedback.  I wasn't terribly 
happy with the previous API proposal, and the comments reflected that. 
Sean Mullan came up with a nice API idea which greatly simplifies the 
goal of helping applications/deployers select a "strong" SecureRandom 
implementation.

I agree with the comments from Xuelei and Micheal StJohns (and others). 
  As Xuelei mentioned, the original scoping a year ago included some of 
those larger configuration ideas, and Michael gave some great additional 
food for thought.  With the JDK 8 M6 deadline quickly drawing near, we 
unfortunately don't have time to explore this further, but what I'm 
proposing should complement and not preclude such future work.

As additional goals for this JEP, I wanted to address three problems in 
the current implementation:

1.  Many customer escalations/complaints of "slow SecureRandom 
performance" because of the limited entropy collection problem on Linux 
boxes, and there's much confusion about how to workaround this problem. 
  (e.g. "file:/dev/./urandom")

2.  The documentation/configuration in the java.security file does not 
match the implementations, and is very confusing when trying to figure 
out #1 above.

3.  It's not clear what the four different Oracle JDK SecureRandom 
implementations do. (Solution:  update the Oracle Security Providers page.)

I think the current proposal addresses these issues.

The highlights:

A Security property called "securerandom.strongAlgorithm".  There are 
defaults for each supported platform, and deployers can change this 
value if they have access to better ones.

static String SecureRandom.getStrongAlgorithm() which obtains the 
property.  The expected usage:

       *     SecureRandom sr = SecureRandom.getInstance(
       *         SecureRandom.getStrongAlgorithm());
       *     ...deleted...
       *     keyPairGenerator.initialize(2048, sr);

Cleaned out the incorrect information in the java.security files.

The default securerandom.source Security property is set to 
"file:/dev/random" to properly reflect the implementation.  (Ideally, 
I'd like to push this back to earlier JDK's.)

If the java.security.egd/securerandom.source properties are set to 
either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be 
preferred to SHA1PRNG.

NativePRNG now respects the java.security.egd/securerandom.source 
properties.

NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. 
  I added two new NativePRNG implementations which are completely 
blocking or nonblocking.  The "securerandom.strongAlgorithm" property 
points to the blocking variant.

I still have some cleanup work to do on the NativePRNG.java file, but 
the rest (minus test cases) is ready in the webrev.02 directory.

     http://cr.openjdk.java.net/~wetmore/6425477/

Thanks,

Brad