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