RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations
weijun.wang at oracle.com
Wed Apr 20 23:55:30 UTC 2016
> On Apr 20, 2016, at 11:13 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> 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
>> 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().
I'll model after Authenticator. That would need some synchronization.
>>>>> 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
>> 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.
> 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.
My understanding is this means not choosing it correctly does not has a security impact. I am also confused on why "when used within a cryptographic module" is emphasized.
> 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?
No. I think it's something like a salt, and in DRBG salt has 2 parts: nonce is automatically provided by vendor, personalization string is provided by caller.
> 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.
Both. I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible 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.
OK I should say I don't think so. :-)
More information about the security-dev