RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Xuelei Fan]

On 4/20/2016 10:14 PM, Wang Weijun wrote:
> 
>> 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?
> 
SSL/TLS considers record sequence number wrapping, too.  The nonce
require at least half-strength randomness, I would like to follow this
requirement.

> How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please.
> 
I may use a 16 bytes array ( 16 * 8 * 2 = 256), and increase for each
acquire.  See sun.security.ssl.Authenticator.acquireAuthenticationBytes().

> 
>>
>>>> ------
>>>> 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.
> 
cannot->can?

> 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.
It's easy, the spec talked about some approaches.  NIST SP 800-90 does
requires it to be unique, users would have found ways to make it.  The
revise is highly desire it to be unique, too. My understanding,
personalization string is used to add additional randomness, so it is
highly desired to be 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".
> 
I'm not sure I understand the sentence:

    When used within a cryptographic module, a personalization string
    is not considered to be a critical security parameter.

The condition "when used within a cryptographic module", and the extra
word "critical" make me confused very much.

I don't understand why use a personalization string if it does not
impact security.  My suggestion to check the unique is more or less
conservative.  Do you know why use personalization string for DRBG?

It's OK to me to have no uniqueness checking if you are sure
personalization string does not impact security in our design, or you
want to delegate the responsibility to users.

>>
>>> 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.
> 
I'm not sure too, so I cannot agree with your #2 comment.  ;-) It's
another more or less conservative.

Xuelei