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
On 1/9/2013 5:47 PM, Xuelei Fan wrote:
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 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 OK if the algorithm name is not standardized.
But then there is a close connection between provider and this security
property. The administrator must be aware of which providers are
supported and what is the provider-private algorithm name before he can
edit the security property. It would be better to describe the behavior
in the spec of the security property.
Not sure about whether it is possible that the provider that support the
provider-private algorithm are not loaded at runtime. If it happens,
the effect to get strong secure random may not work, a weak one may return.
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()
I like this method more. How about just name it as
"getStrongInstance()", or "getStrong()"?
There are two solutions to get this. As this proposal, the 1st one is to
define a security property (pros: the admin can control the behaviors of
strong secure random). 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). Both need to update
the existing providers. Both have pros and cons, I have no preferences
here.
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.
It's reasonable to me.
To decrease the miss-understanding of the method, can we always return
the configured "strong" secure random? If not "strong" secure random
found, throws an exception or return null. I really worry about the case
that applications request a strong one, but get a weak one and
applications may never be able to know that a weak one is got instead.
Xuelei
