Update #3: JEP 123: SecureRandom First Draft and Implementation.
Brad Wetmore
bradford.wetmore at oracle.com
Thu Jan 10 08:40:13 UTC 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