Design review: JEP 273: DRBG-Based SecureRandom Implementations

[Sean Mullan]

On 11/12/2015 07:58 PM, Wang Weijun wrote:
>> What happens if configure is called more than once, or
>> simultaneously by more than one thread?
> The state is reset. The last one rules. The implementation can be
> made synchronized.
>
> * This method can be called multiple times. After each call, this *
> {@code SecureRandom} object must be reseeded.
>
>>>
>>> Instead of a configure method, I would suggest adding new
>>> getInstance methods that take an AlgorithmParameterSpec. This
>>> should simplify the implementation.
> getInstance() has 3 flavors, (), (String) and (Provider). Too many
> new methods to add.

Only 3 more. It would seem to make the implementation simpler, less 
state and synchronization to worry about.

>>> I also think it might be cleaner and simpler to make EntropyInput
>>> an input parameter of DrbgSpec so that you could have a single
>>> AlgorithmParameterSpec parameter (instead of an AlgParamSpec and
>>> EntropyInput) for the getInstance method.
> EntropyInput as a separated parameter means it applies to other
> SecureRandom implementations and not only DRBG. For example, SHA1PRNG
> can also have a specified entropy source. It is also useful to
> describe what reSeed() means.

Ok but it's really just an input parameter, right?

Maybe, you want something like:

public interface SecureRandomSpec extends AlgorithmParameterSpec {

     EntropyInput getEntropyInput();
}

public class DrbgSpec implements SecureRandomSpec {

}

--Sean