On 4/21/2016 7:55 AM, Wang Weijun wrote: > >> 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. > You have already make synchronization.
>> >> 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. OK, go ahead if you are sure. > I even dare not write "Users should provide unique personalization string" in > the spec. That will scare away possible users. > Why scare away possible users? It is pretty easy to use unique strings. I think as spec say highly desire of unique, it would be better to make the recommendation in JDK spec. ;-) What do you mean delegate the responsibility to users (you said "Both") while you don't make the recommendation? >> >>>> >>>>> 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. :-) > OK, go ahead if you are sure of that. Xuelei
