JEP 123: SecureRandom First Draft and Implementation. (original) (raw)

Weijun Wang weijun.wang at oracle.com
Sat Jan 5 09:05:34 UTC 2013

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 engineSetStrongMode will return * the current mode. 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

More information about the security-dev mailing list