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 <code>SecureRandomSpi</code>
* calls from <code>nextBytes()</code> to <code>generateSeed()</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
