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

2013-01-10 Thread Brad Wetmore
arded by Bruce Rich/Austin/IBM on 01/10/2013 11:44 AM - From: Michael StJohns To: Sean Mullan , Xuelei Fan Cc: OpenJDK Dev list , Brad Wetmore Date: 01/09/2013 09:32 PM Subject: Re: Update #2: JEP 123: SecureRandom First Draft and Implementation. Sent by: security-dev-boun...@openjdk.jav

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

2013-01-10 Thread Bruce Rich
/10/2013 11:44 AM - From: Michael StJohns To: Sean Mullan , Xuelei Fan Cc: OpenJDK Dev list , Brad Wetmore Date: 01/09/2013 09:32 PM Subject:Re: Update #2: JEP 123: SecureRandom First Draft and Implementation. Sent by:security-dev-boun...@openjdk.java.net At

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

2013-01-09 Thread Brad Wetmore
I don't see any reason why not. We just need to come up with a good naming convention, and then we can add that into the Standard Algorithms document. The existing names were established years ago, based on functional implementations rather than a specific algorithmic basis. Brad On 1/9/

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

2013-01-09 Thread Michael StJohns
At 09:45 AM 1/9/2013, Sean Mullan wrote: >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. Can this be fixed? There really should be a flavor for this. E

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

2013-01-09 Thread 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" impleme

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

2013-01-09 Thread Xuelei Fan
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 desc

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

2013-01-09 Thread Weijun Wang
It seems to me that setting a security property that always point to the strongest algorithm is like creating an alias for it. How about we generalize this idea? In java.security, alg.alias.securerandom.strongest = SUN:sha1prng Every other provider-based security class can use it. Thanks

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

2013-01-09 Thread Sean Mullan
On 01/09/2013 08:37 AM, Xuelei Fan wrote: Form the implementation of SecureRandom.getStrongAlgorithm(), it is possible that returned value are not "strong" (if the related property is not defined). It's really confusing to the application when it requires a real strong one (for example, for cert

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

2013-01-09 Thread Sean Mullan
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".

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

2013-01-09 Thread Xuelei Fan
Form the implementation of SecureRandom.getStrongAlgorithm(), it is possible that returned value are not "strong" (if the related property is not defined). It's really confusing to the application when it requires a real strong one (for example, for certificate generation), but only get a normal o

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

2013-01-09 Thread Weijun Wang
Which provider will provide this strong algorithm? If multiple do, are they equally strong? I had proposed using alg names like "Native/Strong/NonBlocking" in the meeting. Will it still of help? -Max On Jan 9, 2013, at 7:41 PM, Xuelei Fan wrote: > I like this new proposal. Some minor commen

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

2013-01-09 Thread Xuelei Fan
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 s

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

2013-01-09 Thread Brad Wetmore
One minor omission. On 1/9/2013 12:44 AM, Brad Wetmore wrote: NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. I added two new NativePRNG implementations which are completely blocking or nonblocking. The "securerandom.strongAlgorithm" property points to the blocking va

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

2013-01-09 Thread Brad Wetmore
Greetings, Thanks so much for all of the constructive feedback. I wasn't terribly happy with the previous API proposal, and the comments reflected that. Sean Mullan came up with a nice API idea which greatly simplifies the goal of helping applications/deployers select a "strong" SecureRandom