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

[Brad Wetmore]

Thanks for the feedback.  I also received some privately which had 
similar comments.

Wrapping up several emails into some bullet points:

1.  I like Sean's suggested tweak to the API.  I'm thinking of adjusting 
it slightly.

2.  Xuelei has a point about my fallback of "most preferred" 
implementation may not actually be strong.  And like Max, I've also had 
concerns about "which provider".

In my previous proposal laundry list for SecureRandom, I had something like:

     securerandom.strongAlgorithms=algname1,algname2.provname1,algname3

which addresses both issues.  The property will contain a list of algs 
or algs/providers, and we'll iterate through them.  If we can't create 
an instance of one of these, return a null.

     public static SecureRandom getStrongSecureRandom()

Given these comments, I think I'm going to move forward on this.  The 
application will do:

     SecureRandom sr = SecureRandom.getStrongSecureRandom();

     if (sr == null) {
         // Decide if this is a problem, and whether to recover.
         // sr = new SecureRandom(); or return;
     }

3.  Sean wrote:

 > There's an assumption that the securerandom.strongAlgorithm has been
 > configured appropriately.

Exactly, we'll ship with default values for each platform, and 
programs/deployers can add/subtract as needed.

4.  Xuelei wrote:

 > The 2nd one is to define a SPI method (pros: the
 > admin won't need to set the property. The admin does not always know
 > what kind of providers will be used at runtime).

If I'm reading this comment right, given the pros of the current 
approach, I hesitate letting implementations make comparative strength 
decisions.

Thanks!  I should have a new version out tonight.

Brad




On 1/9/2013 5:47 PM, Xuelei Fan wrote:
> On 1/9/2013 10:45 PM, Sean Mullan wrote:
>> On 01/09/2013 06:41 AM, 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?
>>
>> I think it is unlikely that 2 providers would implement the same
>> SecureRandom algorithm, since the names are not standardized like other
>> cryptographic algorithms such as SHA-256, RSA, etc.
>>
> It's OK if the algorithm name is not standardized.
>
> But then there is a close connection between provider and this security
> property.  The administrator must be aware of which providers are
> supported and what is the provider-private algorithm name before he can
> edit the security property.  It would be better to describe the behavior
> in the spec of the security property.
>
> Not sure about whether it is possible that the provider that support the
> provider-private algorithm are not loaded at runtime.  If it happens,
> the effect to get strong secure random may not work, a weak one may return.
>
>>> It's a little bit
>>> confusing to me to set security property. I would prefer to use "strong".
>>
>> Yes, but grammatically the term "Returns the strong algorithm name"
>> doesn't work. So I think using "strongest" instead is ok and not overly
>> confusing.
>>
>>> 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.
>>
>> Yes, but (2) contains a lot of boilerplate code. Also the app may not
>> have permission to read the security property, so you may have to deal
>> with that too. All of that is taken care of for you in the new method.
>> In my opinion, developers are more likely to use this new feature if we
>> make it as easy as possible.
>>
>> In fact, I thought of an even simpler solution. I think we should
>> replace the new getStrongAlgorithm method with the following method
>> instead:
>>
>>    public static SecureRandom getStrongSecureRandom()
>>
> I like this method more.  How about just name it as
> "getStrongInstance()", or "getStrong()"?
>
> There are two solutions to get this. As this proposal, the 1st one is to
> define a security property (pros: the admin can control the behaviors of
> strong secure random).  The 2nd one is to define a SPI method (pros: the
> admin won't need to set the property. The admin does not always know
> what kind of providers will be used at runtime).  Both need to update
> the existing providers.  Both have pros and cons, I have no preferences
> here.
>
>> which essentially does the following:
>>
>>    SecureRandom.getInstance(SecureRandom.getStrongAlgorithm());
>>
>> This makes it really simple for apps when they just want to use the most
>> secure RNG available. Let's see what Brad thinks about this later.
>>
>>> 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.
>>
>> I respectfully disagree. I think it's a very useful method that avoids a
>> lot of boilerplate code and also the potential issue of not having
>> permission to read the security property.
>>
> It's reasonable to me.
>
> To decrease the miss-understanding of the method, can we always return
> the configured "strong" secure random? If not "strong"  secure random
> found, throws an exception or return null. I really worry about the case
> that applications request a strong one, but get a weak one and
> applications may never be able to know that a weak one is got instead.
>
> Xuelei
>