Allow alternative SecureRandom instances to be created


The may block application startup when there is not enough entropy in the system.

This is due to the usage of NativePRNG which selects /dev/random, which may block indefinitely.

Not sure it is a bug (see, but it is very hard to debug.

Maybe some logging and/or a default option for a weaker random might be something to consider.


Jan Willem Janssen
June 14, 2017, 9:54 AM

Introduced a separate util project that provides the ability to create a secure random instance and moved some of the shared utility code to that project as well. This project is intended to be inlined and as such cannot be resolved during deployment.

All projects that were creating strong instances of secure random by default are now using the new util project instead.

Bram de Kruijff
June 6, 2017, 7:57 AM

Hey , note that you now make the algorithm configurable, but not the provider. Eg with the current patch I can not configure the equivalent of SecureRandom.getInstance("SHA1PRNG","IBMSecureRandom"). Not sure we need it, but as you are making it configurable you might consider going all the way.

Jan Willem Janssen
June 2, 2017, 9:43 AM

I've updated my PR to provide the ability to select a secure random algorithm whenever needed and use the default constructor as default. If we want, we can use the native PRNG (either blocking or non-blocking), and for tests a simpler non-blocking variant can be used (which is the default one selected when calling `new SecureRandom()`).

The PR should fix the blocking of the JWT bundle during startup due to lack of entropy.

Jan Willem Janssen
June 1, 2017, 11:04 AM

I've -1'd the PR for reasons I outlined in its comment. I'm not seeing this as a viable workaround for the moment.

Bram de Kruijff
June 1, 2017, 7:35 AM

Opened a PR with the workaround I currently use (point 6 in previous comment). I think that may actually be good enough until we refactor it and make it configurable?





Bram de Kruijff