JEP 123: SecureRandom First Draft and Implementation.

[Michael StJohns]

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