Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations

[Sean Mullan]

On 01/04/2016 08:17 PM, Wang Weijun wrote:
>
>> On Jan 5, 2016, at 6:59 AM, Sean Mullan <sean.mullan at oracle.com>
>> wrote:
>>
>> Here are some more comments on the API:
>>
>> * EntropyInput:
>>
>> 29  * An interface of a source of entropy input.
>>
>> "interface" is implied, so you can just say "A source of entropy
>> input." Also, I think this interface should be called
>> "EntropySource". To me, "Input" means the byte array that is
>> already populated, whereas "Source" produces those bytes. A
>> sentence or two with more details in the description would also be
>> helpful.
>
> Well, as defined in Section 4 of SP 800-90Ar1, "Entropy Source" means
> real random source based on a physical device. What we need here is
> the "Randomness Source" or "Source of entropy input" (section 2 of
> 800-90B).

Ok, but in what cases would you really want someone to use a source that 
is not based on a physical device? In the default implementation, isn't 
the only case if the securerandom.source property is not set or is not 
correct, and then the SHA1PRNG non-device algorithm is used? Perhaps we 
could have an option which throws an exception and refuses to fall back 
on that for the DRBG mechanisms. Also, whether it is an approved DRBG 
implementation seems like a separate testing or compliance issue to me.

> Shall we call it RandomnessSource?

EntropySource still seems like the best name to me. EntropySource 
implementations produce entropy :)

RandomnessSource may lead to more confusion as to what is the difference 
between that and SecureRandom.

>> Do we want to allow the generated entropy input to be longer than
>> the size requested (see section 7.1 of sp800-90Ar1)? Perhaps, a
>> method such as:
>>
>> byte[] getFullEntropy(int length)
>>
>> might be more suitable, and specify that a byte array longer than
>> the specified length may be returned.
>
> This should be named getEntropy(), because full means every bit of
> the output contains one bit of entropy.
>
> Such a method is OK for most cases, but except for one, CtrDRBG with
> no derivation function, where the entropy input must be full.
> Therefore a getFullEntropy() is needed anyway so I just use it
> everywhere. I also thought that every random source should have a
> conditioning module to convert non-full entropy bytes to full ones.
>
> If this is not true, 2 methods are needed:
>
> byte[] getEntropy(int length); void getFullEntropy(byte[] entropy);
>
> Detailed descriptions will be added on when and which is used.
>
> And I don't think we need to provide any conditioning codes.

If you think getFullEntropy is sufficient, then let's just keep the one 
method.

--Sean