Update #3: JEP 123: SecureRandom First Draft and Implementation.
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
Re: Update #3: JEP 123: SecureRandom First Draft and Implementation.
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
Fw: Update #2: JEP 123: SecureRandom First Draft and Implementation.
+1 IBM already has SP800-90a/SHA256/HASH, SP800-90a/SHA384/HASH, and SP800-90a/SHA512/HASH in our provider, but without standardized names, they are not very useable for the Java community as a whole. Bruce A Rich brich at-sign us dot ibm dot com - Forwarded by Bruce Rich/Austin/IBM on 01/10/2013 11:44 AM - From: Michael StJohns mstjo...@comcast.net To: Sean Mullan sean.mul...@oracle.com, Xuelei Fan xuelei@oracle.com Cc: OpenJDK Dev list security-dev@openjdk.java.net, Brad Wetmore bradford.wetm...@oracle.com 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 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.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST approved deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike
Re: Fw: Update #2: JEP 123: SecureRandom First Draft and Implementation.
Thanks Bruce/Michael, FYI, I've created: 8006041: Create SecureRandom standard algorithm names. against JDK 8 to track this issue, and I had previously filed: 8003584: Consider adding a more modern SecureRandom implementation to add the SP800-90a algorithms in JDK. Brad On 1/10/2013 9:48 AM, Bruce Rich wrote: +1 IBM already has SP800-90a/SHA256/HASH, SP800-90a/SHA384/HASH, and SP800-90a/SHA512/HASH in our provider, but without standardized names, they are not very useable for the Java community as a whole. Bruce A Rich brich at-sign us dot ibm dot com - Forwarded by Bruce Rich/Austin/IBM on 01/10/2013 11:44 AM - From: Michael StJohns mstjo...@comcast.net To: Sean Mullan sean.mul...@oracle.com, Xuelei Fan xuelei@oracle.com Cc: OpenJDK Dev list security-dev@openjdk.java.net, Brad Wetmore bradford.wetm...@oracle.com 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 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.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST approved deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike
Update #2: JEP 123: SecureRandom First Draft and Implementation.
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 implementation. I agree with the comments from Xuelei and Micheal StJohns (and others). As Xuelei mentioned, the original scoping a year ago included some of those larger configuration ideas, and Michael gave some great additional food for thought. With the JDK 8 M6 deadline quickly drawing near, we unfortunately don't have time to explore this further, but what I'm proposing should complement and not preclude such future work. As additional goals for this JEP, I wanted to address three problems in the current implementation: 1. Many customer escalations/complaints of slow SecureRandom performance because of the limited entropy collection problem on Linux boxes, and there's much confusion about how to workaround this problem. (e.g. file:/dev/./urandom) 2. The documentation/configuration in the java.security file does not match the implementations, and is very confusing when trying to figure out #1 above. 3. It's not clear what the four different Oracle JDK SecureRandom implementations do. (Solution: update the Oracle Security Providers page.) I think the current proposal addresses these issues. The highlights: A Security property called securerandom.strongAlgorithm. There are defaults for each supported platform, and deployers can change this value if they have access to better ones. static String SecureRandom.getStrongAlgorithm() which obtains the property. The expected usage: * SecureRandom sr = SecureRandom.getInstance( * SecureRandom.getStrongAlgorithm()); * ...deleted... * keyPairGenerator.initialize(2048, sr); Cleaned out the incorrect information in the java.security files. The default securerandom.source Security property is set to file:/dev/random to properly reflect the implementation. (Ideally, I'd like to push this back to earlier JDK's.) If the java.security.egd/securerandom.source properties are set to either file:/dev/random or file:/dev/urandom, NativePRNG will be preferred to SHA1PRNG. NativePRNG now respects the java.security.egd/securerandom.source properties. 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 variant. I still have some cleanup work to do on the NativePRNG.java file, but the rest (minus test cases) is ready in the webrev.02 directory. http://cr.openjdk.java.net/~wetmore/6425477/ Thanks, Brad
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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 variant on Unix-like OS's (Solaris/Linux/MacOS), and Windows-PRNG on Windows. Brad
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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? It's a little bit
confusing to me to set security property. I would prefer to use strong.
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.
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.
Please consider it.
Thanks,
Xuelei
On 1/9/2013 4:44 PM, Brad Wetmore wrote:
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
implementation.
I agree with the comments from Xuelei and Micheal StJohns (and others).
As Xuelei mentioned, the original scoping a year ago included some of
those larger configuration ideas, and Michael gave some great additional
food for thought. With the JDK 8 M6 deadline quickly drawing near, we
unfortunately don't have time to explore this further, but what I'm
proposing should complement and not preclude such future work.
As additional goals for this JEP, I wanted to address three problems in
the current implementation:
1. Many customer escalations/complaints of slow SecureRandom
performance because of the limited entropy collection problem on Linux
boxes, and there's much confusion about how to workaround this problem.
(e.g. file:/dev/./urandom)
2. The documentation/configuration in the java.security file does not
match the implementations, and is very confusing when trying to figure
out #1 above.
3. It's not clear what the four different Oracle JDK SecureRandom
implementations do. (Solution: update the Oracle Security Providers page.)
I think the current proposal addresses these issues.
The highlights:
A Security property called securerandom.strongAlgorithm. There are
defaults for each supported platform, and deployers can change this
value if they have access to better ones.
static String SecureRandom.getStrongAlgorithm() which obtains the
property. The expected usage:
* SecureRandom sr = SecureRandom.getInstance(
* SecureRandom.getStrongAlgorithm());
* ...deleted...
* keyPairGenerator.initialize(2048, sr);
Cleaned out the incorrect information in the java.security files.
The default securerandom.source Security property is set to
file:/dev/random to properly reflect the implementation. (Ideally,
I'd like to push this back to earlier JDK's.)
If the java.security.egd/securerandom.source properties are set to
either file:/dev/random or file:/dev/urandom, NativePRNG will be
preferred to SHA1PRNG.
NativePRNG now respects the java.security.egd/securerandom.source
properties.
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 variant.
I still have some cleanup work to do on the NativePRNG.java file, but
the rest (minus test cases) is ready in the webrev.02 directory.
http://cr.openjdk.java.net/~wetmore/6425477/
Thanks,
Brad
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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 xuelei@oracle.com 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? It's a little bit
confusing to me to set security property. I would prefer to use strong.
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.
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.
Please consider it.
Thanks,
Xuelei
On 1/9/2013 4:44 PM, Brad Wetmore wrote:
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
implementation.
I agree with the comments from Xuelei and Micheal StJohns (and others).
As Xuelei mentioned, the original scoping a year ago included some of
those larger configuration ideas, and Michael gave some great additional
food for thought. With the JDK 8 M6 deadline quickly drawing near, we
unfortunately don't have time to explore this further, but what I'm
proposing should complement and not preclude such future work.
As additional goals for this JEP, I wanted to address three problems in
the current implementation:
1. Many customer escalations/complaints of slow SecureRandom
performance because of the limited entropy collection problem on Linux
boxes, and there's much confusion about how to workaround this problem.
(e.g. file:/dev/./urandom)
2. The documentation/configuration in the java.security file does not
match the implementations, and is very confusing when trying to figure
out #1 above.
3. It's not clear what the four different Oracle JDK SecureRandom
implementations do. (Solution: update the Oracle Security Providers page.)
I think the current proposal addresses these issues.
The highlights:
A Security property called securerandom.strongAlgorithm. There are
defaults for each supported platform, and deployers can change this
value if they have access to better ones.
static String SecureRandom.getStrongAlgorithm() which obtains the
property. The expected usage:
* SecureRandom sr = SecureRandom.getInstance(
* SecureRandom.getStrongAlgorithm());
* ...deleted...
* keyPairGenerator.initialize(2048, sr);
Cleaned out the incorrect information in the java.security files.
The default securerandom.source Security property is set to
file:/dev/random to properly reflect the implementation. (Ideally,
I'd like to push this back to earlier JDK's.)
If the java.security.egd/securerandom.source properties are set to
either file:/dev/random or file:/dev/urandom, NativePRNG will be
preferred to SHA1PRNG.
NativePRNG now respects the java.security.egd/securerandom.source
properties.
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 variant.
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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 one and the behaviors (blocking or not, strong or
weak) of the normal one is unknown. The horrible thing may be that the
caller never know that it is not a strong one, as the method name,
getStrongAlgorithm, implies that the returned value is strong but not
weak.
That's another reason that I don't like this new method
(SecureRandom.getStrongAlgorithm()). We don't have such problems if we
only define the new security property without this new method.
Xuelei
On 1/9/2013 7:41 PM, 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? It's a little bit
confusing to me to set security property. I would prefer to use strong.
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.
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.
Please consider it.
Thanks,
Xuelei
On 1/9/2013 4:44 PM, Brad Wetmore wrote:
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
implementation.
I agree with the comments from Xuelei and Micheal StJohns (and others).
As Xuelei mentioned, the original scoping a year ago included some of
those larger configuration ideas, and Michael gave some great additional
food for thought. With the JDK 8 M6 deadline quickly drawing near, we
unfortunately don't have time to explore this further, but what I'm
proposing should complement and not preclude such future work.
As additional goals for this JEP, I wanted to address three problems in
the current implementation:
1. Many customer escalations/complaints of slow SecureRandom
performance because of the limited entropy collection problem on Linux
boxes, and there's much confusion about how to workaround this problem.
(e.g. file:/dev/./urandom)
2. The documentation/configuration in the java.security file does not
match the implementations, and is very confusing when trying to figure
out #1 above.
3. It's not clear what the four different Oracle JDK SecureRandom
implementations do. (Solution: update the Oracle Security Providers page.)
I think the current proposal addresses these issues.
The highlights:
A Security property called securerandom.strongAlgorithm. There are
defaults for each supported platform, and deployers can change this
value if they have access to better ones.
static String SecureRandom.getStrongAlgorithm() which obtains the
property. The expected usage:
* SecureRandom sr = SecureRandom.getInstance(
* SecureRandom.getStrongAlgorithm());
* ...deleted...
* keyPairGenerator.initialize(2048, sr);
Cleaned out the incorrect information in the java.security files.
The default securerandom.source Security property is set to
file:/dev/random to properly reflect the implementation.
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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
Max
On 01/09/2013 10:51 PM, Sean Mullan wrote:
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 certificate generation),
but only get a normal one and the behaviors (blocking or not, strong or
weak) of the normal one is unknown. The horrible thing may be that the
caller never know that it is not a strong one, as the method name,
getStrongAlgorithm, implies that the returned value is strong but not
weak.
There's an assumption that the securerandom.strongAlgorithm has been
configured appropriately. For the OpenJDK we will set this property to
what we think is the strongest algorithm on each platform. Yes, someone
can later change or unset the property, but this assumes they can modify
the security properties file, so worse things can happen in that case.
--Sean
That's another reason that I don't like this new method
(SecureRandom.getStrongAlgorithm()). We don't have such problems if we
only define the new security property without this new method.
Xuelei
On 1/9/2013 7:41 PM, 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? It's a little bit
confusing to me to set security property. I would prefer to use
strong.
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.
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.
Please consider it.
Thanks,
Xuelei
On 1/9/2013 4:44 PM, Brad Wetmore wrote:
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
implementation.
I agree with the comments from Xuelei and Micheal StJohns (and others).
As Xuelei mentioned, the original scoping a year ago included some of
those larger configuration ideas, and Michael gave some great
additional
food for thought. With the JDK 8 M6 deadline quickly drawing near, we
unfortunately don't have time to explore this further, but what I'm
proposing should complement and not preclude such future work.
As additional goals for this JEP, I wanted to address three problems in
the current implementation:
1. Many customer escalations/complaints of slow SecureRandom
performance because of the limited entropy collection problem on Linux
boxes, and there's much confusion about how to workaround this problem.
(e.g. file:/dev/./urandom)
2. The documentation/configuration in the java.security file does not
match the implementations, and is very confusing when trying to figure
out #1 above.
3. It's not clear what the four different Oracle JDK SecureRandom
implementations do. (Solution: update the Oracle Security Providers
page.)
I think the current proposal addresses
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST approved deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike
Re: Update #2: JEP 123: SecureRandom First Draft and Implementation.
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/2013 7:31 PM, Michael StJohns wrote: 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.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST approved deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike
Re: JEP 123: SecureRandom First Draft and Implementation.
Hi Brad et al -
I think its possible you're focusing too much on implementations and less on
the class of random number generator.
There are basically three types of RNG - a true RNG which uses a noise source
of some sort for its entropy (and which may be *conditioned* in its output to
deal with the noise source specifics), a pseudo-RNG of various qualities
(contrast rand() and SHA1PRNG), and a hybrid RNG consisting of a pseudo-RNG
backed by and seeded by a true RNG.
As I understand it, you're looking for both the simple just give me a good
random number generator and the I want a good random number generator and I
want to know what the heck its doing, and I want to specify certain things.
So first thing - shouldn't SecureRandom have a getInstance with an
AlgorithmParameters argument instead of adding the getStrong stuff? I'd
use this for a hybrid RNG to pair a PRNG with a TRNG.
Second thing, for the PRNG and hybrid instances, you probably should have a
concept of re-seeding intervals and a way to set them. Instead of (or in
addition to) the generateSeed/setSeed pair, you could add a
setSeeder(SecureRandom rand, long reseedInterval) where the reseed interval is
in bits or bytes.
For a TRNG, you mostly want to be able to characterize how much data is
available how fast. So getSizeOfEntropyPool() - current fill in bits,
getMaxSizeOfEntropyPool() - max fill, getBitRate() - number of bits per time
interval, getMinSizeOfEntropyPool() - the minimum number of bits that must be
in the pool to return anything. Maybe getResetTime() - returns a long of the
number of millis needed from reset to bit generation.
For the names, add defaultTRNG, defaultPRNG and defaultHybrid to the
standard instance names. Have new SecureRandom() return an instance of
defaultHybrid if available, otherwise defaultPRNG.
For PRNGs, it would help if you could return (via getAlgorithm()) the OID of
the underlying function, as well as the bit strength if available.
I've been dealing with RNGs and FIPS for the last few months or so - which
explains most of the above. I'd especially like it if the default PRNG ended
up being one of the ones in SP800-90A rather than what's there now.
Later, Mike
At 08:49 PM 1/4/2013, Brad Wetmore wrote:
I had an ugly chicken/egg bug I just figured out, so didn't get a chance to
respond to your/Weijun/Xuelei's comments.
For the APIs, it's pretty clear I need some clearer explanations here, and
maybe some adjustments.
I wouldn't suggest you spend much more time on the internals as things will
change a bit and I just found another issue, but in case you want to see what
I had in mind, there's a new webrev:
http://cr.openjdk.java.net/~wetmore/6425477
See: webrev.01
addressed #4 below.
in NativePRNG, if the file URL isn't readable, it defaults to
/dev/random instead of disabling this implementation.
couple bug fixes.
BTW, on #3 (@code), the Oracle Javadoc comment page still says to use
code/code. I originally didn't change it because there were so many
instances of code.
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
Thanks,
Brad
On 1/4/2013 2:03 PM, Sean Mullan wrote:
Just some initial comments on the API. I have not looked at the code yet.
1. getStrongSecureRandom says:
* If the underlying SPI implementation does not support the
* {@link SecureRandomSpi.engineSetStrongMode(boolean)
* SecureRandomSpi.engineSetStrongMode(boolean)} method,
* then a wrapper class will redirect codeSecureRandomSpi/code
* calls from codenextBytes()/code to codegenerateSeed()/code.
Can you explain in a bit more detail what this means? Is the
SecureRandom object that is returned the same whether mode is true or
false, even if the underlying implementation could be upgraded to
support a strong mode?
2. The name for the method getStrongMode seems a bit odd since it
returns a boolean. How about isStrong instead?
3. Nit: Use {@code} instead of code/code
4. Consider marking getStrongSecureRandom and getStrongMode final. I
think the other methods on SecureRandom are not final because the SPI
was added later, unlike other security SPI classes.
--Sean
On 01/02/2013 08:58 PM, Brad Wetmore wrote:
Hi,
Please review the API/impl for JEP 123:
http://openjdk.java.net/jeps/123
http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/
Oracle folks, there is also the internal CCC that needs review. The bug
id is 6425477.
There are several SecureRandom implementations in Oracle's JDK, and
together with the configuration options in the java.security file, it
can be very confusing for users to understand. As part of the work on
JEP 123, I took a comprehensive look at the different SecureRandom
implementations and how we got here.
There are these implementations:
PKCS11:
Direct calls to the native PKCS11 library. Only enabled
by default on Solaris, but available for
Re: JEP 123: SecureRandom First Draft and Implementation.
Just some initial comments on the API. I have not looked at the code yet.
1. getStrongSecureRandom says:
* If the underlying SPI implementation does not support the
* {@link SecureRandomSpi.engineSetStrongMode(boolean)
* SecureRandomSpi.engineSetStrongMode(boolean)} method,
* then a wrapper class will redirect codeSecureRandomSpi/code
* calls from codenextBytes()/code to codegenerateSeed()/code.
Can you explain in a bit more detail what this means? Is the
SecureRandom object that is returned the same whether mode is true or
false, even if the underlying implementation could be upgraded to
support a strong mode?
2. The name for the method getStrongMode seems a bit odd since it
returns a boolean. How about isStrong instead?
3. Nit: Use {@code} instead of code/code
4. Consider marking getStrongSecureRandom and getStrongMode final. I
think the other methods on SecureRandom are not final because the SPI
was added later, unlike other security SPI classes.
--Sean
On 01/02/2013 08:58 PM, Brad Wetmore wrote:
Hi,
Please review the API/impl for JEP 123:
http://openjdk.java.net/jeps/123
http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/
Oracle folks, there is also the internal CCC that needs review. The bug
id is 6425477.
There are several SecureRandom implementations in Oracle's JDK, and
together with the configuration options in the java.security file, it
can be very confusing for users to understand. As part of the work on
JEP 123, I took a comprehensive look at the different SecureRandom
implementations and how we got here.
There are these implementations:
PKCS11:
Direct calls to the native PKCS11 library. Only enabled
by default on Solaris, but available for any OS. No difference
between seed/random.
NativePRNG:
uses /dev/random and /dev/urandom for seeds/random numbers
respectively. Doesn't exist on Windows.
SHA1PRNG:
Available on all platforms. By default, uses a confusing mix of
/dev/[u]random for internal seeding and external seed
generation, along with a SHA1 MessageDigest for
generating random numbers. The properties (below) control
seeding, but in a confusing manner.
Windows-PRNG:
Direct calls to the MSCAPI library, only available for Windows.
No difference between seed/random.
There were two main points for this JEP:
1. Provide an API that allows applications to indicate whether they
want the strongest-possible (possibly blocking) values, or if just
regular values will do.
2. See if we can clarify the configuration model, and eliminate some of
the confusion caused by the securerandom.source/java.security.egd
variables.
This second point has caused a lot of pain for
developers/deployers/support. The workaround of specifying
file:/dev/./urandom or file:///dev/urandom instead of
file:/dev/urandom has to be one of the most unintuitive ever. [1] ;)
The default value of the variable is changed to file:/dev/random to
reflect the actual implementation we've been shipping since JDK 5, but
will also install NativePRNG as more preferred over the SHA1PRNG.
Otherwise, the part of the implementation stays the same, and is now
better documented in the java.security file.
We'll also be updating the Oracle Provider documentation to reflect the
implementations, but that work will be done later.
Thanks,
Brad
[1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101
Re: JEP 123: SecureRandom First Draft and Implementation.
Forwarding some relevant comments: Brad Set #1 of 2: From weijun.wang (at) oracle (dot) com: SecureRandom.java: First you have If mode is set to true, successive calls... then you also says the return value may not necessarily be the same as the original object. Shall I use the return value or this? Also, what if I call the method with false? The spec says the strong mode may block. Does this imply that the weak mode never blocks? SecureRandomSpi.java: * Calls to codeengineSetStrongMode/code will return * the current codemode/code. You mean engineGetStrongMode? java.security: 100 # On Unix-like systems (for example, Solaris/Linux/MacOS), there is a 101 # separate NativePRNG implementation that obtains seed and random numbers 102 # from special device files. If a file is specified and does not exist, 103 # NativePRNG will not be available. file is the only currently 104 # supported protocol type. If a file is specified and it does exist, will NatievPRNG read from *this* specified file? Or still from some mysterious special devide file? 106 # In addition, if file:/dev/random or file:/dev/urandom is 107 # specified, the NativePRNG implementation will be more preferred than 108 # SHA1PRNG. Is more needed when preferred is used? Also, I haven't read the impl codes for a while, but by specifying one of the 2 sources above, is SHA1PRNG almost the same as NativePRNG? I'll read the code changes later. Thanks Max
Re: JEP 123: SecureRandom First Draft and Implementation.
Forwarding some relevant comments: Brad Set #2 of 2: From xuelei.fan (at) oracle (dot) com: From the specification, looks like that a provider would have to support both high-quality and normal-quality mode. Otherwise, SecureRandomSpi.engineSetStrongMode() should throw exception if the provider does not support high-quality mode. It does not look intuitive to me, I think a few (many be only a very few) providers may only support normal-quality or blocking mode. From the spec of SecureRandom.getStrongSecureRandom(), my understand is that the returned value may be not configured with the request mode. I mean that if application request to use high-quality secure random, the returned value may be not a high-quality secure random because the underlying provider does not support the SecureRandomSpi.engineSetStrongMode() or only supports normal-quality mode. It's confusing. Or am I miss-understanding something? BTW, the returned value of SecureRandom.getStrongSecureRandom() may not inherit the secure properties from the original caller instance, for example, the initialized seed. I think it would be better to call setSeed again on the returned value to add additional randomness. The code may look like: SecureRandom sr = ...; sr.setSeed(...); SecureRandom newSR = sr.getStrongSecureRandom(true); newSR.setSeed(...); // looks like useless, but it is useful // because the previous seed isn't inherited. I think the quality of a secure random depends on the provider. The quality may be a attribute of a provider. Personally, I like more to use block or non-block mode. I think you may have though about to use the algorithm characteristics, as the one proposed in JEP 123 description: sr = new SecureRandom( ..., SR_HIGHQUALITY|SR_NON_BLOCKING); It looks more intuitive to me, and the API may look like: // look for providers that supports the particular mode. + SecureRandom(boolean block); + SecureRandom(byte seed, boolean block); + SecureRandom.getInstance(String algorithm, boolean block); + SecureRandom.isBlockMode(); We may not need to update getInstance(String, Provider) because block or non-block is a character of a provider (get the value by isBlockMode()). Just for your consideration, may be too later. Xuelei On 1/2/2013 5:58 PM, Brad Wetmore wrote: Hi, Please review the API/impl for JEP 123: http://openjdk.java.net/jeps/123 http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ Oracle folks, there is also the internal CCC that needs review. The bug id is 6425477. There are several SecureRandom implementations in Oracle's JDK, and together with the configuration options in the java.security file, it can be very confusing for users to understand. As part of the work on JEP 123, I took a comprehensive look at the different SecureRandom implementations and how we got here. There are these implementations: PKCS11: Direct calls to the native PKCS11 library. Only enabled by default on Solaris, but available for any OS. No difference between seed/random. NativePRNG: uses /dev/random and /dev/urandom for seeds/random numbers respectively. Doesn't exist on Windows. SHA1PRNG: Available on all platforms. By default, uses a confusing mix of /dev/[u]random for internal seeding and external seed generation, along with a SHA1 MessageDigest for generating random numbers. The properties (below) control seeding, but in a confusing manner. Windows-PRNG: Direct calls to the MSCAPI library, only available for Windows. No difference between seed/random. There were two main points for this JEP: 1. Provide an API that allows applications to indicate whether they want the strongest-possible (possibly blocking) values, or if just regular values will do. 2. See if we can clarify the configuration model, and eliminate some of the confusion caused by the securerandom.source/java.security.egd variables. This second point has caused a lot of pain for developers/deployers/support. The workaround of specifying file:/dev/./urandom or file:///dev/urandom instead of file:/dev/urandom has to be one of the most unintuitive ever. [1] ;) The default value of the variable is changed to file:/dev/random to reflect the actual implementation we've been shipping since JDK 5, but will also install NativePRNG as more preferred over the SHA1PRNG. Otherwise, the part of the implementation stays the same, and is now better documented in the java.security file. We'll also be updating the Oracle Provider documentation to reflect the implementations, but that work will be done later. Thanks, Brad [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101
Re: JEP 123: SecureRandom First Draft and Implementation.
I had an ugly chicken/egg bug I just figured out, so didn't get a chance
to respond to your/Weijun/Xuelei's comments.
For the APIs, it's pretty clear I need some clearer explanations here,
and maybe some adjustments.
I wouldn't suggest you spend much more time on the internals as things
will change a bit and I just found another issue, but in case you want
to see what I had in mind, there's a new webrev:
http://cr.openjdk.java.net/~wetmore/6425477
See: webrev.01
addressed #4 below.
in NativePRNG, if the file URL isn't readable, it defaults to
/dev/random instead of disabling this implementation.
couple bug fixes.
BTW, on #3 (@code), the Oracle Javadoc comment page still says to use
code/code. I originally didn't change it because there were so many
instances of code.
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
Thanks,
Brad
On 1/4/2013 2:03 PM, Sean Mullan wrote:
Just some initial comments on the API. I have not looked at the code yet.
1. getStrongSecureRandom says:
* If the underlying SPI implementation does not support the
* {@link SecureRandomSpi.engineSetStrongMode(boolean)
* SecureRandomSpi.engineSetStrongMode(boolean)} method,
* then a wrapper class will redirect codeSecureRandomSpi/code
* calls from codenextBytes()/code to codegenerateSeed()/code.
Can you explain in a bit more detail what this means? Is the
SecureRandom object that is returned the same whether mode is true or
false, even if the underlying implementation could be upgraded to
support a strong mode?
2. The name for the method getStrongMode seems a bit odd since it
returns a boolean. How about isStrong instead?
3. Nit: Use {@code} instead of code/code
4. Consider marking getStrongSecureRandom and getStrongMode final. I
think the other methods on SecureRandom are not final because the SPI
was added later, unlike other security SPI classes.
--Sean
On 01/02/2013 08:58 PM, Brad Wetmore wrote:
Hi,
Please review the API/impl for JEP 123:
http://openjdk.java.net/jeps/123
http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/
Oracle folks, there is also the internal CCC that needs review. The bug
id is 6425477.
There are several SecureRandom implementations in Oracle's JDK, and
together with the configuration options in the java.security file, it
can be very confusing for users to understand. As part of the work on
JEP 123, I took a comprehensive look at the different SecureRandom
implementations and how we got here.
There are these implementations:
PKCS11:
Direct calls to the native PKCS11 library. Only enabled
by default on Solaris, but available for any OS. No difference
between seed/random.
NativePRNG:
uses /dev/random and /dev/urandom for seeds/random numbers
respectively. Doesn't exist on Windows.
SHA1PRNG:
Available on all platforms. By default, uses a confusing mix of
/dev/[u]random for internal seeding and external seed
generation, along with a SHA1 MessageDigest for
generating random numbers. The properties (below) control
seeding, but in a confusing manner.
Windows-PRNG:
Direct calls to the MSCAPI library, only available for Windows.
No difference between seed/random.
There were two main points for this JEP:
1. Provide an API that allows applications to indicate whether they
want the strongest-possible (possibly blocking) values, or if just
regular values will do.
2. See if we can clarify the configuration model, and eliminate some of
the confusion caused by the securerandom.source/java.security.egd
variables.
This second point has caused a lot of pain for
developers/deployers/support. The workaround of specifying
file:/dev/./urandom or file:///dev/urandom instead of
file:/dev/urandom has to be one of the most unintuitive ever. [1] ;)
The default value of the variable is changed to file:/dev/random to
reflect the actual implementation we've been shipping since JDK 5, but
will also install NativePRNG as more preferred over the SHA1PRNG.
Otherwise, the part of the implementation stays the same, and is now
better documented in the java.security file.
We'll also be updating the Oracle Provider documentation to reflect the
implementations, but that work will be done later.
Thanks,
Brad
[1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101
JEP 123: SecureRandom First Draft and Implementation.
Hi, Please review the API/impl for JEP 123: http://openjdk.java.net/jeps/123 http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ Oracle folks, there is also the internal CCC that needs review. The bug id is 6425477. There are several SecureRandom implementations in Oracle's JDK, and together with the configuration options in the java.security file, it can be very confusing for users to understand. As part of the work on JEP 123, I took a comprehensive look at the different SecureRandom implementations and how we got here. There are these implementations: PKCS11: Direct calls to the native PKCS11 library. Only enabled by default on Solaris, but available for any OS. No difference between seed/random. NativePRNG: uses /dev/random and /dev/urandom for seeds/random numbers respectively. Doesn't exist on Windows. SHA1PRNG: Available on all platforms. By default, uses a confusing mix of /dev/[u]random for internal seeding and external seed generation, along with a SHA1 MessageDigest for generating random numbers. The properties (below) control seeding, but in a confusing manner. Windows-PRNG: Direct calls to the MSCAPI library, only available for Windows. No difference between seed/random. There were two main points for this JEP: 1. Provide an API that allows applications to indicate whether they want the strongest-possible (possibly blocking) values, or if just regular values will do. 2. See if we can clarify the configuration model, and eliminate some of the confusion caused by the securerandom.source/java.security.egd variables. This second point has caused a lot of pain for developers/deployers/support. The workaround of specifying file:/dev/./urandom or file:///dev/urandom instead of file:/dev/urandom has to be one of the most unintuitive ever. [1] ;) The default value of the variable is changed to file:/dev/random to reflect the actual implementation we've been shipping since JDK 5, but will also install NativePRNG as more preferred over the SHA1PRNG. Otherwise, the part of the implementation stays the same, and is now better documented in the java.security file. We'll also be updating the Oracle Provider documentation to reflect the implementations, but that work will be done later. Thanks, Brad [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101
