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

[Xuelei Fan]

Form the implementation of SecureRandom.getStrongAlgorithm(), it is
possible that returned value are not "strong" (if the related property
is not defined).  It's really confusing to the application when it
requires a real strong one (for example, for certificate generation),
but only get a normal one and the behaviors (blocking or not, strong or
weak) of the normal one is unknown.  The horrible thing may be that the
caller never know that it is not a "strong" one, as the method name,
getStrongAlgorithm, implies that the returned value is "strong" but not
weak.

That's another reason that I don't like this new method
(SecureRandom.getStrongAlgorithm()). We don't have such problems if we
only define the new security property without this new method.

Xuelei

On 1/9/2013 7:41 PM, Xuelei Fan 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
>