Design review: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

> On 2015年11月14日, at 上午1:56, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> 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.

OK.

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

Sound good.

I'll update the APIs.

Thanks
Max

> 
> --Sean