> On Apr 20, 2016, at 11:13 PM, Xuelei Fan <xuelei....@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 > 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().
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 >>>>> 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? Yes. > >> 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. :-) Thanks Max > > Xuelei
