RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations
xuelei.fan at oracle.com
Thu Apr 21 00:07:04 UTC 2016
On 4/21/2016 7:55 AM, Wang Weijun wrote:
>> 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.
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.
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
>>>>> 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.
More information about the security-dev