Code review request, CR 7145837, jsse/runtime, a little performance improvement on the usage of SecureRandom

[Xuelei Fan]

Thanks for the review.

On Feb 16, 2012, at 7:28 AM, Brad Wetmore <bradford.wetmore at oracle.com> wrote:

> Looks ok to me too, but it seems a shame to keep this SecureRandom instance for a single test (AES_256) during cipher initialization.  Once the condition is test, and the result is added to the cache, the SecureRandom instance is never used again.
> 
I think why we wanted to check the condition every time is that the cache may be cleaned, and the security provider may be dynamically changed during JVM.  As the new generated cipherBox is never used, so we don't care about its secure random generator.  And the real secureRandom in the SSLContext will be used in the following operations.

Thanks,
Xuelei

> Brad
> 
> 
> 
> On 2/15/2012 8:03 AM, Chris Hegarty wrote:
>> Looks fine to me, but I'm sure someone closer to the security area may
>> also want to review.
>> 
>> -Chris.
>> 
>> On 15/02/2012 15:45, Xuelei Fan wrote:
>>> I believe I have replied the mail. But cannot find the mail in the mail
>>> system. It's weird.
>>> 
>>> New webrev: http://cr.openjdk.java.net/~xuelei/7145837/webrev.01/.
>>> 
>>> Moved secureRandom into BulkCipher block.
>>> 
>>> Thanks,
>>> Xuelei
>>> 
>>> 
>>> On 2/15/2012 11:06 PM, Chris Hegarty wrote:
>>>> Just out of curiosity, why is secureRandom defined in the outer class
>>>> rather than privately in BulkCipher??
>>>> 
>>>> -Chris.
>>>> 
>>>> On 15/02/2012 14:21, Xuelei Fan wrote:
>>>>> webrev: http://cr.openjdk.java.net/~xuelei/7145837/webrev/
>>>>> 
>>>>> To use only one instance of SecureRandom for dummy/useless CipherBox
>>>>> initialization.
>>>>> 
>>>>> Thanks,
>>>>> Xuelei