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....@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
>
