RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Xuelei Fan]

On 4/21/2016 9:24 AM, Wang Weijun wrote:
> 
>> On Apr 21, 2016, at 8:07 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>> I'll model after Authenticator. That would need some synchronization.
>>>
>> You have already make synchronization.
> 
> You mean synchronized for instantiateIfNecessary? But this time I need to synchronize on cc which is static.
> 
I see.

>>
>>> I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users.
>>>
>> Why scare away possible users?  It is pretty easy to use unique strings.
> 
> I don't think so.
OK.  I should say I think it is pretty easy.

> 
> For example, the NIST recommend a network card address and a library uses it as the personalization string. The NIC address is unique, but how to prevent an application call the library method twice and create 2 DRBGs with the same string?
> 
;-) You choose an example that the string is not unique for twice calling.

>> I think as spec say highly desire of unique, it would be better to make
>> the recommendation in JDK spec.  ;-)
> 
> Because of the reason above, I don't want to put this burden on the user.
> 
I would suggest you have some words for the recommendation.  ;-) But
it's up to you.

I would guess your final decision is that you will not say the
recommendation in JDK spec.  OK, go ahead.

Xuelei

>> What do you mean delegate the
>> responsibility to users (you said "Both") while you don't make the
>> recommendation?
> 
> The string itself is provided by user and we cannot modify it. Therefore if the string must be unique, then it's user's responsibility to make it unique and the best we can do is check and throw IAEs.
> 
> --Max
>