RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations
xuelei.fan at oracle.com
Wed Apr 20 04:53:15 UTC 2016
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:
>> 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
> "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
> 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.
More information about the security-dev