On 4/20/2016 12:00 PM, Wang Weijun wrote: > >> On Apr 20, 2016, at 11:34 AM, Xuelei Fan <xuelei....@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
