Update #2: JEP 123: SecureRandom First Draft and Implementation. (original) (raw)
Sean Mullan sean.mullan at oracle.com
Wed Jan 9 14:45:35 UTC 2013
- Previous message (by thread): Update #2: JEP 123: SecureRandom First Draft and Implementation.
- Next message (by thread): Update #2: JEP 123: SecureRandom First Draft and Implementation.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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". I think the method name and specification should use the same word, "strong" or "strongest". Using both may cause some miss-understanding. My very first feeling of the "strongest" is that it may depends on both providers and algorithms. If two providers support the same "strongest" algorithms, which one is the strongest?
I 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.
It's a little bit confusing to me to set security property. I would prefer to use "strong".
Yes, but grammatically the term "Returns the strong algorithm name" doesn't work. So I think using "strongest" instead is ok and not overly confusing.
2. Do we really need the SecureRandom.getStrongAlgorithm()?
As the strong algorithm is specified by security property. I think it should be enough to use Java.Security.getProperty(). We properly don't need a new method here. We properly need to add some additional description about the default value of strong algorithm that is recommended to use when the security property is not set. Look at the examples, With this method, the application call looks like (1): String strongAlg = SecureRandom.getStrongAlgorithm(); SecureRandom sr = SecureRandom.getInstance(strongAlg); While using security property, the application call (2): String strongAlg = Security.getProperty("securerandom.strongAlgorithm"); SecureRandom sr = SecureRandom.getInstance(strongAlg); if (strongAlg == null) { strongAlg = new SecureRandom(). } else { sr = SecureRandom.getInstance(strongAlg); } As we have defined security property, the (2) code style is always useable. Looks like that the (1) style is not really necessary, because (2) does the same thing.
Yes, but (2) contains a lot of boilerplate code. Also the app may not have permission to read the security property, so you may have to deal with that too. All of that is taken care of for you in the new method. In my opinion, developers are more likely to use this new feature if we make it as easy as possible.
In fact, I thought of an even simpler solution. I think we should replace the new getStrongAlgorithm method with the following method instead:
public static SecureRandom getStrongSecureRandom()
which essentially does the following:
SecureRandom.getInstance(SecureRandom.getStrongAlgorithm());
This makes it really simple for apps when they just want to use the most secure RNG available. Let's see what Brad thinks about this later.
What I want to express here is that we properly don't need to add a new method to get security property in SecureRandom class. Adding a new security property should be enough.
I respectfully disagree. I think it's a very useful method that avoids a lot of boilerplate code and also the potential issue of not having permission to read the security property.
--Sean
- Previous message (by thread): Update #2: JEP 123: SecureRandom First Draft and Implementation.
- Next message (by thread): Update #2: JEP 123: SecureRandom First Draft and Implementation.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]