[jcifs] SecureRandom.nextBytes Takes Too Long

[Oleg Alexeyev]

Hello,

If it's still of any interest:
In fact, SecureRandom (more precisely its implementation in Sun's JCA
provider - "SHA1PRNG") has been behaving this way since it was introduced
till JDK 1.4. The matter is that it needs to find some secure entropy to use
as a seed and there was no native implementation for that till 1.4, where
it's implemented using /dev/random on *nixes and using MS Crypto API on
Windows. The original implementation creates many threads, which call GC
eventually, and tries to obtain the entropy from the timings produced by
these threads. The details of the PRNG were not widely published and it
might be even questionable how secure it is. As to the performance, it not
only takes much time (too much for GUI apps) to init, but also might make
the app much less responsive during the init (depending on JVM
implementation) because of frequent requests to GC.

So, for apps utilizing Java crypto stuff I'd recommend to switch to JDK
1.4.x if at all possible since the new implementations remove all this
burden and might provide more secure entropy source.

If switching to 1.4.x is not an option, there is a workaround for *nixes -
use Cryptix (http://cryptix.org/) (or just read /dev/random :).

However, SecureRandom might not be needed for many purposes, like generating
challenges, IVs, salt etc. Perhaps, some people might even argue that it's
not a good idea at all to use a secure PRNG, the same one which is used to
generate keys etc., for such purposes as this might expose info (very
little, but absolutely unnecessarily) about the state of the PRNG, which
must be kept secret.

As to the performance details, Sun's implementation (the algorithm name is
"SHA1PRNG") uses SHA-1 digest to produce the random sequence and to update
its internal state, so of course it can't be faster than a linear
congruential PRNG implemented in Random class.

Yours,

--
oleg


> -----Original Message-----
> From: jcifs-bounces+oleg.alexeyev=arcadia.spb.ru at lists.samba.org
> [mailto:jcifs-bounces+oleg.alexeyev=arcadia.spb.ru at lists.samba.org]On
> Behalf Of eglass1 at comcast.net
> Sent: Thursday, September 11, 2003 12:25 PM
> To: Michael B Allen
> Cc: jcifs at samba.org
> Subject: Re: [jcifs] SecureRandom.nextBytes Takes Too Long
>
>
>
> > The random.nextBytes(clientChallenge) calls in the NPA constructors kill
> > my CPU and takes almost 10 seconds to run. This make program startup
> > pretty painful. Any ideas?
> >
>
> Try changing java.security.SecureRandom to just plain old
> java.util.Random; it
> is an order of magnitude faster (a cryptographically strong PRNG
> is probably
> not a requirement for us anyways).
>
> It is kind of strange that it takes *that* long though -- I can run the
> following in about 1 second (not counting the 2 second sleep):
>
> public class test {
>
>     public static void main(String[] args) throws Exception {
>         byte[] dest = new byte[8];
>         java.util.Random sec = new java.security.SecureRandom();
>         Thread.sleep(2000); // sleep a bit to get into a steady state
>         long start = System.currentTimeMillis();
>         for (int i = 0; i < 300000; i++) sec.nextBytes(dest);
>         System.out.println(System.currentTimeMillis() - start);
>     }
>
> }
>
> Changing SecureRandom to Random cuts that down to ~100ms.
>
> Anyways, see if that helps; otherwise, there may be something
> else going on
> here that would warrant some investigation.
>
> Eric