Update #3: JEP 123: SecureRandom First Draft and Implementation. (original) (raw)

Xuelei Fan xuelei.fan at oracle.com
Thu Jan 10 09:05:03 UTC 2013

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

More information about the security-dev mailing list