On 08/02/2018 11:17, Colm O hEigeartaigh wrote:
Hi Francesco,
On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:
I see... what about wrapping SecureRandom in ThreadLocal instead, e.g. replacing
What does wrapping SecureRandom in ThreadLocal buy us from a performance POV?
As java.util.Radom's (since SecureRandom extends it) javadoc:
https://docs.oracle.com/javase/8/docs/api/java/util/Random.html
states,
"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.
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/
