JEP 123: SecureRandom First Draft and Implementation.

[Weijun Wang]

On 01/05/2013 07:18 AM, Brad Wetmore wrote:
> 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?

With the current design, what you really need to warn the users is that 
after getStrongSecureRandom(true) is called the behavior of the existing 
instance is not defined. It may be stronger or may stay the same. In 
fact, the "get" in the name implies the method is non-destructive (to 
internal states), so this will be a little confusing.

Also, you might need to specify if the returned instance is seeded or 
not (or if it depends on the existing one).

In your webrev, if I read correctly, most (but one) of the 
SecureRandomSpi impls does not really honor the strongMode flag. Can 
they just extends a new abstract class named AlwaysStrongSecureRandomSpi?

Thanks
Max

>
> The spec says the strong mode "may block". Does this imply that the
> "weak" mode never blocks?
>
> SecureRandomSpi.java:
>
>       * Calls to <code>engineSetStrongMode</code> will return
>       * the current <code>mode</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
>
>