On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò <[email protected] > 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 < >>> [email protected]> >>> >>>> 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ò < >>>>> [email protected]> 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
