tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: SecureRandom instance for session ID generation using [SHA1PRNG] took [510,962] milliseconds !
Date Fri, 03 Oct 2014 18:41:02 GMT
Am 03.10.2014 um 14:01 schrieb Christopher Schultz:
> Hash: SHA256
> Martin,
> On 10/3/14 5:48 AM, Martin Hamant wrote:
>> Le 03/10/2014 11:26, Martin Hamant a écrit :
>>> The virtual (qemu) server runs with 4GB RAM
>> Sorry, The hypervisor is KVM. The VM is running on top of
>> OpenStack So... This could lead somewhere as I am reading
> OpenStack
> or not, running on a VM usually means that the underlying OS
> is providing the source of entropy. If your physical machine is
> heavily virtualized, you may have multiple entropy sinks constantly
> draining your source(s() of entropy.
> If you wait for a while, things will recover. If you find you are
> constantly blocking waiting for more randomness to be available from
> your random source, you basically have 3 options:
> 1. Suffer through it. Just keep waiting.
> 2. Use a poor source of randomness, like /dev/urandom on Linux.
>     I wouldn't recommend this for any kind of production deployment,
>     since the entropy source is "watered-down". You can't rely on it
>     for important things like encryption (including SSL) and really
>     anything that requires random numbers that are as random as
>     possible (like session ids).
> 3. Get yourself a hardware entropy source. You can buy USB keys that
>     do this kind of thing. Make sure whatever you get is compatible
>     with your OS and accessible by Java (better yet, get one that will
>     simply dump its randomness into /dev/random).

... and in case you are heading for the urandom solution and are sing 
JDK before 8, you should use e.g.

and *not*

For background info look at

or more officially


This has been fixed in JDK8 though (finally).



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message