RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

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

> 
>> 
>>> 
>>>>> ------
>>>>> Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string
>>>>> should be unique for all instantiations of the same DRBG mechanism type".
>>>>> 
>>>>> Please check the unique for the personalization string in the
>>>>> implementation.
>>>> 
>>>> "Should" is not "shall" (section 4, terms).
>>> "should" is recommended. Better to adhere to.
>>> 
>>>> Two other reasons:
>>>> 
>>>> 1. Checking for uniqueness needs to save all strings in memory.
>>>> 
>>> I see, but you need to find a smart solution.  Add some randomness, or
>>> make some checking.  It may be a security issue if you don't check the
>>> unique.
>> 
>> I cannot add any randomness. Personalization string is provided by a user and I don't think I cannot modify it.
>> 
> cannot->can?

Yes.

> 
>> So if we want to make it unique, it will be a requirement of users to make it unique. I don't want to enforce this because I don't think users have the capability to make it unique.
> It's easy, the spec talked about some approaches.  NIST SP 800-90 does
> requires it to be unique, users would have found ways to make it.  The
> revise is highly desire it to be unique, too. My understanding,
> personalization string is used to add additional randomness, so it is
> highly desired to be unique.
> 
>> Finally nobody will use a personalization string.
>> 
>> 8.7.1 has more description on personalization strings, and it "is not considered to be a critical security parameter".
>> 
> I'm not sure I understand the sentence:
> 
>    When used within a cryptographic module, a personalization string
>    is not considered to be a critical security parameter.
> 
> The condition "when used within a cryptographic module", and the extra
> word "critical" make me confused very much.

My understanding is this means not choosing it correctly does not has a security impact. I am also confused on why "when used within a cryptographic module" is emphasized.

> 
> I don't understand why use a personalization string if it does not
> impact security.  My suggestion to check the unique is more or less
> conservative.  Do you know why use personalization string for DRBG?

No. I think it's something like a salt, and in DRBG salt has 2 parts: nonce is automatically provided by vendor, personalization string is provided by caller.

> 
> 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. I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users.

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

Thanks
Max

> 
> Xuelei