RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

> On Apr 20, 2016, at 12:53 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 4/20/2016 12:00 PM, Wang Weijun wrote:
>> 
>>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> On 4/19/2016 9:09 PM, Xuelei Fan wrote:
>>>> On 4/15/2016 9:
>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ 
>>> 
>>> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java
>>> ===================================================================
> 
>>> ------
>>> 670     nonce = longToByteArray(cc.incrementAndGet());
>>> 685     private static byte[] longToByteArray(long l)
>>> 
>>> The nonce is leading with "sun.drbg", and following by a 8-bytes integer
>>> value.  This scheme only provider 8-bytes randomness.  Looks like the
>>> quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1)
>>> for 256-bit strength.
>> 
>> 8.6.7 allows it to be a "monotonically increased sequence number".
>> 
> I don't think it means you can downgrade the strength.  8-byte integer
> value may wrap and is not monotonically increased.  A sequence number
> does not limited to 8-bytes integer.  It can be unlimited.

Really? You are worried about more than 2^64 instances of DRBG?

How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please.


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

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

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

Thanks
Max

> 
> Xuelei
>