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

[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".  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