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

Brad Wetmore bradford.wetmore at oracle.com
Thu Jan 10 00:40:13 PST 2013


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


More information about the security-dev mailing list