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

[Weijun Wang]

Which provider will provide this strong algorithm? If multiple do, are they equally strong?

I had proposed using alg names like "Native/Strong/NonBlocking" in the meeting. Will it still of help?

-Max

On Jan 9, 2013, at 7:41 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:

> I like this new proposal.  Some minor comments here.
> 
> 1. The name of SecureRandom.getStrongAlgorithm()
> 
>   In the specification of the method and java.security, the word
> "strongest" is used to describe the algorithm. While the name use the
> word "strong".  I think the method name and specification should use the
> same word, "strong" or "strongest". Using both may cause some
> miss-understanding.
> 
>   My very first feeling of the "strongest" is that it may depends on
> both providers and algorithms. If two providers support the same
> "strongest" algorithms, which one is the strongest?  It's a little bit
> confusing to me to set security property. I would prefer to use "strong".
> 
> 2. Do we really need the SecureRandom.getStrongAlgorithm()?
> 
> As the strong algorithm is specified by security property.  I think it
> should be enough to use Java.Security.getProperty().  We properly don't
> need a new method here.  We properly need to add some additional
> description about the default value of strong algorithm that is
> recommended to use when the security property is not set.
> 
> Look at the examples,
> 
>  With this method, the application call looks like (1):
>    String strongAlg = SecureRandom.getStrongAlgorithm();
>    SecureRandom sr = SecureRandom.getInstance(strongAlg);
> 
>  While using security property, the application call (2):
>    String strongAlg =
>        Security.getProperty("securerandom.strongAlgorithm");
>    SecureRandom sr = SecureRandom.getInstance(strongAlg);
>    if (strongAlg == null) {
>        strongAlg = new SecureRandom().
>    } else {
>        sr = SecureRandom.getInstance(strongAlg);
>    }
> 
> As we have defined security property, the (2) code style is always
> useable.  Looks like that the (1) style is not really necessary, because
> (2) does the same thing.
> 
> What I want to express here is that we properly don't need to add a new
> method to get security property in SecureRandom class.  Adding a new
> security property should be enough.
> 
> Please consider it.
> 
> Thanks,
> Xuelei
> 
> On 1/9/2013 4:44 PM, Brad Wetmore wrote:
>> 
>> 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
>