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

[Xuelei Fan]

The new specification looks fine to me.

Thanks,
Xuelei

On 1/10/2013 4:40 PM, Brad Wetmore wrote:
> The third version is now out (minus test cases), and is ready in the
> webrev.03 directory.
> 
>     http://cr.openjdk.java.net/~wetmore/6425477/
> 
> The only change is the API as we discussed.
> 
> Brad
> 
> 
> 
> 
> On 1/9/2013 7:21 PM, Brad Wetmore wrote:
>> 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
>>
>>
>>