RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Xuelei Fan]

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.

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

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

Xuelei