[15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering

Weijun Wang weijun.wang at oracle.com
Sat Jun 6 00:55:57 UTC 2020


I don't know how complex this is. Will it become another map (set) that needs to be thread-safe and has an order?

If this is not a documented spec and just added for compatibility. How about we just keep the current design but inside getDefaultSecureRandomAlgorithm() if firstPrng is not in the map we return another one?

--Max

> On Jun 6, 2020, at 2:00 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Right, I try to keep the impl simple as I am not aware of any property removal usage.
> 
> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added.
> 
> Valerie
> 
> On 6/5/2020 7:54 AM, Weijun Wang wrote:
>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available".
>> 
>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way.
>> 
>> Unfortunately there is no ConcurrentLinkedHashMap.
>> 
>> --Max
>> 
>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula <prasadarao.koppula at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Looks good to me, one question
>>> 
>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove?
>>> 
>>> Thanks,
>>> Prasad.K
>>> 
>>>> -----Original Message-----
>>>> From: Valerie Peng
>>>> Sent: Friday, June 5, 2020 2:52 AM
>>>> To: security-dev at openjdk.java.net
>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo
>>>> based on registration ordering
>>>> 
>>>> Hi, Sean,
>>>> 
>>>> Thanks for the review and feedback. Webrev updated:
>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/
>>>> 
>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by
>>>> debugging output. I have removed it and made both method static.
>>>> 
>>>> I will wait for others' review comments also.
>>>> 
>>>> Thanks,
>>>> Valerie
>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote:
>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Could someone help reviewing this fix? This change keep tracks of the
>>>>>> first registered SecureRandom algorithm and returns it upon the
>>>>>> request of SecureRandom class.
>>>>> This looks good to me. I would recommend that Max or someone else
>>>>> review it as well.
>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/
>>>>> A couple of minor comments, feel free to fix or ignore.
>>>>> 
>>>>> * SecureRandom.java
>>>>> 
>>>>> 879             // For SUN provider, we use
>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO
>>>>> 
>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/
>>>>> 
>>>>> * Provider.java
>>>>> 
>>>>> 1156     private String parseSecureRandomPut(String name, String
>>>>> value) {
>>>>> 
>>>>> Could be static if you also make getTypeAndAlgorithm static, I think.
>>>>> 
>>>>> --Sean




More information about the security-dev mailing list