JEP 123: SecureRandom First Draft and Implementation.

[Brad Wetmore]

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
>>
>