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

Reply via email to