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

[Weijun Wang]

It seems to me that setting a security property that always point to the 
strongest algorithm is like creating an alias for it. How about we 
generalize this idea?

In java.security,

    alg.alias.securerandom.strongest = SUN:sha1prng

Every other provider-based security class can use it.

Thanks
Max


On 01/09/2013 10:51 PM, Sean Mullan wrote:
> On 01/09/2013 08:37 AM, Xuelei Fan wrote:
>> 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.
>
> There's an assumption that the securerandom.strongAlgorithm has been
> configured appropriately. For the OpenJDK we will set this property to
> what we think is the strongest algorithm on each platform. Yes, someone
> can later change or unset the property, but this assumes they can modify
> the security properties file, so worse things can happen in that case.
>
> --Sean
>
>>
>> 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
>>>
>>
>