I support Peter at al's plan to add an API that ThreadLocalRandom et al can use to get some system entropy without unbounded class dependency loading.
It should not surprise anyone that at Google, we are most interested in running on Linux, so while we're waiting for a proper fix to happen we are locally applying a simpler patch that tries explicitly /dev/urandom, falling back to SecureRandom if necessary: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ThreadLocalRandom-system-entropy/ On Mon, Jul 14, 2014 at 1:54 PM, Bernd <e...@zusammenkunft.net> wrote: > SecureRandom is unfortunatelly pretty complex. It is interpreting the > seed url in some way (the configuration you mentioned behave very special > since Java 6) , it is mixing seed and continues data and it reorders the > implementations used. > > JEP 123 intended to clear things, but getInstanceStrong() (which nobody > uses?!) did not improve things IMHO. > > Bernd > > PS: I think the webrev changed since then, but the mail from Brad > describes the problem well: > http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html > Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" < > oleksandr.ote...@oracle.com>: > > Can someone summarize what happened? >> >> SecureRandom used to get entropy from /dev/random, which is configurable >> through a policy file to /dev/urandom. Has this changed? >> >> Alex >> >> On 12/07/2014 00:33, Martin Buchholz wrote: >> >> Thanks to Peter for digging into the secure seed generator classes and >> coming up with a patch. Openjdk security folks, please review. I confess >> to getting lost whenever I try to orient myself in the twisty maze of seed >> generator implementation files. >> >> Anyways, it seems important to have prngs like ThreadLocalRandom be >> able to get a few bits of seed entropy without loading hundreds of classes >> and without occupying any file descriptors permanently. Perhaps at Google >> we will go back to writing some simple non-portable startup code to read >> /dev/urandom until openjdk security team comes up with a more principled >> solution (but one that doesn't drag in too much machinery). >> >> >> _______________________________________________ >> Concurrency-interest mailing >> listConcurrency-interest@cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest >> >> >>
