> On Apr 20, 2016, at 12:53 PM, Xuelei Fan <xuelei....@oracle.com> wrote: > > 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.
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 >
