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 > > >