Everyone will not agree cause of this reseeding latency - not only at boot - but guess this thread is complete now ;) Le 18 juin 2016 21:59, "Bjorn Danielsson" <[email protected]> a écrit :
> Better because more secure and less unnecessary blocking: > > On any normal Linux server, urandom is seeded from /dev/random at boot > time, and from there on it works like any randomly seeded PRNG, except > that it's better than SHA1PRNG since the Linux algorithm has been vetted > by the cryptographic community, and it's also better since urandom can > take advantage of any extra entropy that the kernel makes available as > time passes. > > We all know that this is a JVM issue rather than anything to do with > Tomcat or TomEE, but the unnecessary blocking due to suboptimal > SecureRandom initialization tends to be a recurring question on all > kinds of Java platform forums, since many years. And I think the > /dev/./urandom thing is something that deserves to be put to sleep now. > > -- > Bjorn Danielsson > Cuspy Code AB > > > Romain Manni-Bucau <[email protected]> wrote: > > Does it mean it is better cause faster? For crypto concern I suspect you > > will get both point of views cause of the reseeding difference so up to > you. > > > > Fact are: > > - ./jre/lib/security/java.security contains as default: > > securerandom.source=file:/dev/random > > - tomcat/tomee only rely on the JVM setup > > - urandom is less secured than random on machines with a low entropy > (check > > the 2 paragraphs there > > > https://github.com/torvalds/linux/blob/5469dc270cd44c451590d40c031e6a71c1f637e8/drivers/char/random.c#L109 > ) > > but likely close if the entropy is good enough. Means if it blocks it is > > less secured. If you go down in the code you see urandom can reuse the > same > > seeding where random shouldn't ( > > > https://github.com/torvalds/linux/blob/5469dc270cd44c451590d40c031e6a71c1f637e8/drivers/char/random.c#L987 > > ) > > > > Of course the "is it the case for me" of the last point is the one you > have > > to decide against to know if urandom is fine or not. Point 1 shows the > JVM > > choice ;). > > > > To make it even simpler: depends the OS, some just ln -s urandom on > random > > :) > > > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > > <http://www.tomitribe.com> | JavaEE Factory > > <https://javaeefactory-rmannibucau.rhcloud.com> > > > > 2016-06-18 19:01 GMT+02:00 Bjorn Danielsson < > > [email protected]>: > > > >> For Java 8, I believe using file:/dev/urandom is better since it > >> avoids SHA1PRNG and it avoids blocking even when seeding SecureRandom. > >> It simply uses /dev/urandom for everything. > >> > >> Here is a good article explaining why /dev/urandom is the way to go: > >> > >> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ > >> > >> -- > >> Bjorn Danielsson > >> Cuspy Code AB > >> > >> > >> Andy Gumbrecht <[email protected]> wrote: > >> > I've found that this can help: > >> > > >> > CATALINA_OPTS=-Djava.security.egd=file:/dev/./urandom > >> > > >> > Your path might be different, but you get the idea. > >> > > >> > Andy. > >> > > >> > http://www.tomitribe.com - @AndyGeeDe - On a small screen device. > >> > On 17 Jun 2016 19:16, "paulhr" <[email protected]> wrote: > >> > > >> >> Install of haveged fixed the issue. It was even available on dnf. > >> >> > >> >> The other option was audio-entroyd. But I found it to be poorly > >> documented > >> >> and hard to find an audio source to feed the randomness that is > needed. > >> >> > >> >> > >> >> *dnf install haveged.* > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> View this message in context: > >> >> > >> > http://tomee-openejb.979440.n4.nabble.com/Three-minutes-to-perform-one-step-during-startup-tp4678934p4678946.html > >> >> Sent from the TomEE Users mailing list archive at Nabble.com. > >> >> > >> >
