On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:

>
>
> "Instances of |java.util.Random| are threadsafe. However, the concurrent
> use of the same |java.util.Random| instance across threads may encounter
> contention and consequent poor performance.  Consider instead using
> ThreadLocalRandom in multithreaded designs."
>
> Looking around the Internet, I've seen suggestions to either user
> ThreadLocalRandom or to wrap SecureRandom in Threadlocal to alleviate this
> issue.
>

I'm just wondering if it could actually lead to worse performance if we
have multiple wrapped SecureRandom instances blocking on /dev/random
(without setting it to /dev/urandom)?

Colm.


>
> Regards.
>
> Also, we'll need to add to the reference guide the hint to set
>>>
>>> -Djava.security.egd=file:/dev/./urandom
>>>
>>> for Tomcat and other Java EE containers on Linux
>>>
>>> Yes I think that's OK.
>>
>> Colm.
>>
>>
>> WDYT?
>>>
>>> On Mon, Feb 5, 2018 at 12:25 PM, Colm O hEigeartaigh <
>>> cohei...@apache.org>
>>>
>>>> wrote:
>>>>
>>>> No, my query got passed on to someone else, still waiting to hear
>>>> back....
>>>>
>>>>> Colm.
>>>>>
>>>>> On Mon, Feb 5, 2018 at 7:44 AM, Francesco Chicchiriccò <
>>>>> ilgro...@apache.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> thanks for the feedback go to so far.
>>>>>>
>>>>>> I know from IRC that Colm has been exploring the security feasibility
>>>>>> with some of his contacts:  any results so far?
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>>
>>>>>> On 30/01/2018 08:24, Francesco Chicchiriccò wrote:
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>>> any feedback on this?
>>>>>>> If no one sees issues with that I'll proceed as indicated.
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> On 24/01/2018 17:54, Francesco Chicchiriccò wrote:
>>>>>>>
>>>>>>> Hi all (and Colm in particular, as this should be in your chords),
>>>>>>>
>>>>>>>> we are currently basing all operations requiring random generation
>>>>>>>> (mainly tokens used during double opt-in and password reset, and
>>>>>>>> password
>>>>>>>> values for specific cases) on SecureRandom [1].
>>>>>>>>
>>>>>>>> SecureRandom has, however, some performance issues which were
>>>>>>>> solved,
>>>>>>>> starting with Java 7, by ThreadLocalRandom [2]; with Java 8 an
>>>>>>>> improvement
>>>>>>>> was made [3] to retain security by setting the system property
>>>>>>>> 'java.util.secureRandomSeed' to true.
>>>>>>>>
>>>>>>>> Shall we:
>>>>>>>>
>>>>>>>> 1. suggest to set
>>>>>>>>
>>>>>>>> -Djava.security.egd=file:/dev/./urandom
>>>>>>>>
>>>>>>>> for Tomcat and other Java EE containers on Linux, and
>>>>>>>>
>>>>>>>> 2. suggest to set
>>>>>>>>
>>>>>>>> -Djava.util.secureRandomSeed=true
>>>>>>>>
>>>>>>>> for Tomcat and other Java EE containers, and
>>>>>>>>
>>>>>>>> 3. replace SecureRandom with ThreadLocalRandom in [1]
>>>>>>>>
>>>>>>>> ?
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>>
>>>>>>>> [1] https://github.com/apache/syncope/blob/2_0_X/common/lib/src/
>>>>>>>> main/java/org/apache/syncope/common/lib/SecureTextRandomPro
>>>>>>>> vider.java#L29
>>>>>>>> [2] https://docs.oracle.com/javase/7/docs/api/java/util/concurre
>>>>>>>> nt/ThreadLocalRandom.html
>>>>>>>> [3] https://docs.oracle.com/javase/8/docs/api/java/util/concurre
>>>>>>>> nt/ThreadLocalRandom.html
>>>>>>>>
>>>>>>>> --
>>> Francesco Chicchiriccò
>>>
>>> Tirasa - Open Source Excellence
>>> http://www.tirasa.net/
>>>
>>> Member at The Apache Software Foundation
>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
>>> http://home.apache.org/~ilgrosso/
>>>
>>>
>>>
>>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to