Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

On 08/02/2018 11:38, Francesco Chicchiriccò wrote: On 08/02/2018 11:37, Colm O hEigeartaigh wrote: On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò wrote: "Instances of |java.util.Random| are threadsafe. However, the concurrent use of the same |java.util.Random|

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

On 08/02/2018 11:37, Colm O hEigeartaigh wrote: On Thu, Feb 8, 2018 at 10:29 AM, Francesco Chicchiriccò 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

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

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

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

On 08/02/2018 11:17, Colm O hEigeartaigh wrote: Hi Francesco, On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò wrote: I see... what about wrapping SecureRandom in ThreadLocal instead, e.g. replacing What does wrapping SecureRandom in ThreadLocal buy us from a

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

Hi Francesco, On Wed, Feb 7, 2018 at 12:12 PM, Francesco Chicchiriccò 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? > Also, we'll need to add

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

On 07/02/2018 13:02, Colm O hEigeartaigh wrote: Hi Francesco, The feedback I have got is that the algorithm used in ThreadLocalRandom is not secure enough to be considered a SecureRandom. So I think it's probably not OK to switch if we are using it to generate tokens unfortunately. I see...

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

Hi Francesco, The feedback I have got is that the algorithm used in ThreadLocalRandom is not secure enough to be considered a SecureRandom. So I think it's probably not OK to switch if we are using it to generate tokens unfortunately. Colm. On Mon, Feb 5, 2018 at 12:25 PM, Colm O hEigeartaigh

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

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ò wrote: > Hi, > thanks for the feedback go to so far. > > I know from IRC that Colm has been exploring the security feasibility with >

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

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

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

Hi, +1 for me. Best regards, Matteo 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

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

Hi all, for me definitely +1. Best regards, Andrea Il 24/01/2018 17:54, Francesco Chicchiriccò ha scritto: 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

Re: [PROPOSAL] Replace SecureRandom with ThreadLocalRandom

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

[PROPOSAL] Replace SecureRandom with ThreadLocalRandom

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