RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Xuelei Fan]

On 4/21/2016 7:55 AM, Wang Weijun wrote:
> 
>> On Apr 20, 2016, at 11:13 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>> Really? You are worried about more than 2^64 instances of DRBG?
>>>
>> SSL/TLS considers record sequence number wrapping, too.  The nonce
>> require at least half-strength randomness, I would like to follow this
>> requirement.
>>
>>> How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please.
>>>
>> I may use a 16 bytes array ( 16 * 8 * 2 = 256), and increase for each
>> acquire.  See sun.security.ssl.Authenticator.acquireAuthenticationBytes().
> 
> I'll model after Authenticator. That would need some synchronization.
> 
You have already make synchronization.

>>
>> It's OK to me to have no uniqueness checking if you are sure
>> personalization string does not impact security in our design, or you
>> want to delegate the responsibility to users.
> 
> Both.
OK, go ahead if you are sure.

> 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 think as spec say highly desire of unique, it would be better to make
the recommendation in JDK spec.  ;-) What do you mean delegate the
responsibility to users (you said "Both") while you don't make the
recommendation?

>>
>>>>
>>>>> 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness?
>>>>>
>>>> null is special.  If "entropy+nonce+null" is safe,
>>>> "entropy+nonce+'constant'" may be problematic for some crypto operation.
>>>
>>> I'm not sure of this.
>>>
>> I'm not sure too, so I cannot agree with your #2 comment.  ;-) It's
>> another more or less conservative.
> 
> OK I should say I don't think so. :-)
> 
OK, go ahead if you are sure of that.

Xuelei