Design review: JEP 273: DRBG-Based SecureRandom Implementations

Wang Weijun weijun.wang at oracle.com
Fri Nov 13 00:58:37 UTC 2015


> On Nov 12, 2015, at 11:23 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Hi Max,
> 
> Still reviewing, but a couple of initial comments ..
> 
> On 11/09/2015 09:54 AM, Wang Weijun wrote:
>> Hi All
>> 
>> The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at
>> 
>>   https://bugs.openjdk.java.net/browse/JDK-8051408
>> 
>> Some notes before the text:
>> 
>> 1. Mainly, new methods are added to SecureRandom to match DRBG functions:
>> 
>>  - configure: choosing the algorithms and parameters
> 
> 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.

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

Thanks
Max

> 
> --Sean




More information about the security-dev mailing list