CODEWITHSUNDEEP
javasecurityrandomcryptography
ngn
ngn

Reputation: 7902

SecureRandom: init once or every time it is needed?

Our team is using a SecureRandom to generate a list of key pairs (the SecureRandom is passed to a KeyPairGenerator). We cannot agree on which of the following two options to use:

  1. Create a new instance every time we need to generate a key pair

  2. Initialize a static instance and use it for all key pairs

Which approach is generally better and why?

ADDED: My gut feeling is that the second option is more secure. But my only argument is a theoretical attack based on the assumption that the pseudorandomness is derived from the current timestamp: someone may see the creation time of the key pair, guess timestamps in the surrounding time interval, compute the possible pseudorandom sequences, and obtain the key material.

ADDED: My assumption about determinism based on a timestamp was wrong. That's the difference between Random and SecureRandom. So, it looks like the answer is: in terms of security it doesn't really matter.

Upvotes: 35

Views: 18195

Answers (7)

Charlie Reitzel
Charlie Reitzel

Reputation: 935

I decided to ask the Java compiler. Short answer is that, yes, re-using the SecureRandom object has some performance benefits but is no bettor or worse wrt actual randomness. This is purely a tuning issue. Not a security issue.

Note, however, it takes a little while for the JIT to kick in so you see the benefits. The take-away is that for heavy/frequent use, definitely re-use the object. For infrequent use, you might be better off use a new object every time.

Results

warm up 
-----------------------------
default seed - re-use - 1807 ms
explicit seed - re-use - 835 ms
constant seed - new every time - 1044 ms
default seed - new every time - 1621 ms
-----------------------------
interation 0
-----------------------------
default seed - re-use - 412 ms
explicit seed - re-use - 418 ms
constant seed - new every time - 955 ms
default seed - new every time - 1676 ms
-----------------------------
interation 1
-----------------------------
default seed - re-use - 389 ms
explicit seed - re-use - 369 ms
constant seed - new every time - 893 ms
default seed - new every time - 1498 ms

Source

package foo;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import java.security.SecureRandom;
import java.util.HashSet;
import java.util.Set;

import org.junit.BeforeClass;
import org.junit.Test;

public class SecureRandomTest {
    
    static long elapsedMillis( long startNs ) {
        long now = System.nanoTime();
        return (now - startNs) / 1_000_000;
    }
    final static long seed = 123456789123456L;
    final static int nIter = 1000000;
    
    public static void main(String[] args) {
        warmup();
        SecureRandomTest test = new SecureRandomTest();
        for ( int ix = 0; ix < 5; ++ix ) {
            test.run(ix);
        }
    }
    
    void run(int ix) {
        System.out.printf( "interation %d\n-----------------------------\n", ix);
        secure_random_default_seed_reuse();
        secure_random_constant_seed_reuse();
        secure_random_constant_seed();
        secure_random_default_seed();
        System.out.println("-----------------------------");
    }

    /* Warm up JVM/JIT */
    @BeforeClass
    public static void warmup() {
        new SecureRandomTest().run(-1);
    }

    @Test
    public void secure_random_constant_seed() {
        long started = System.nanoTime();
        int nDupes = 0, ix = 0;
        Set<Long> generated = new HashSet<>(nIter);
        for ( /**/; ix < nIter; ++ix) {
            SecureRandom rand = new SecureRandom();
            rand.setSeed(seed);
            long xRand = rand.nextLong();
            if ( !generated.add(xRand) ) {
                ++nDupes;
            }
        }
        assertEquals( "Unexpected # of dupes " + nDupes + ", ix == " + ix, nIter-1, nDupes );
        System.out.printf( "constant seed - new every time - %d ms\n", elapsedMillis(started) );
    }

    @Test
    public void secure_random_constant_seed_reuse() {
        long started = System.nanoTime();
        int nDupes = 0, ix = 0;
        SecureRandom rand = new SecureRandom();
        rand.setSeed(seed);
        Set<Long> generated = new HashSet<>(nIter);
        for ( /**/; ix < nIter; ++ix) {
            long xRand = rand.nextLong();
            if ( !generated.add(xRand) ) {
                ++nDupes;
            }
        }
        assertTrue( "Unexpected # of dupes " + nDupes + ", ix == " + ix, 0 == nDupes );
        System.out.printf( "explicit seed - re-use - %d ms\n", elapsedMillis(started) );
    }

    @Test
    public void secure_random_default_seed() {
        long started = System.nanoTime();
        int nDupes = 0, ix = 0;
        Set<Long> generated = new HashSet<>(nIter);
        for ( /**/; ix < nIter; ++ix) {
            long xRand = new SecureRandom().nextLong();
            if ( !generated.add(xRand) ) {
                ++nDupes;
            }
        }
        assertTrue( "Unexpected # of dupes " + nDupes + ", ix == " + ix, 0 == nDupes );
        System.out.printf( "default seed - new every time - %d ms\n", elapsedMillis(started) );
    }

    @Test
    public void secure_random_default_seed_reuse() {
        long started = System.nanoTime();
        int nDupes = 0, ix = 0;
        SecureRandom rand = new SecureRandom();
        Set<Long> generated = new HashSet<>(nIter);
        for ( /**/; ix < nIter; ++ix) {
            long xRand = rand.nextLong();
            if ( !generated.add(xRand) ) {
                ++nDupes;
            }
        }
        assertTrue( "Unexpected # of dupes " + nDupes + ", ix == " + ix, 0 == nDupes );
        System.out.printf( "default seed - re-use - %d ms\n", elapsedMillis(started) );
    }
}

Upvotes: 1

Kapil Khattar
Kapil Khattar

Reputation:

Every SecureRandom generation is seeded from some entropy pool. Depending on the OS used, this might be the entropy pool maintained by the OS like /dev/random on Linux, or might be something that the JVM cooks up. In some earlier implementations, the Sun JVM used to spawn a number of threads and use their timing data to create the seed.

Creating a new SecureRandom on every call might cause slow down of the application since creation of the seed might be blocking. Its better to reuse the a statically created instance, but make sure to reseed it after a fixed number random bytes are extracted from it.

You may want to create a wrapper over a SecureRandom instance which counts the number of bytes extracted in nextBytes or generateSeed calls and after a number of bytes, reseeds the internal SecureRandom instance by using system entropy pool.

The wrapper approach however is not possible on Java on Linux since the SecureRandom instance you get from new SecureRandom() is nothing but a wrapper on /dev/random and every call for nextBytes or generateSeed actually drains the OS entropy pool. On Linux and Solaris, its better to use a JCE provider for SecureRandom creation.

Upvotes: 7

Gowri
Gowri

Reputation: 1331

Unlike the java.util.Random class, the java.security.SecureRandom class must produce non-deterministic output on each call.

What that means is, in case of java.util.Random, if you were to recreate an instance with the same seed each time you needed a new random number, you would essentially get the same result every time. However, SecureRandom is guaranteed to NOT do that - so, creating a single instance or creating a new one each time does not affect the randomness of the random bytes it generates.

So, from just normal good coding practices view point, why create too many instances when one will do?

Upvotes: 20

Matthew McCullough
Matthew McCullough

Reputation: 17597

For SecureRandom you would want to consider occasionally reseeding (using system entropy in most cases) via a call like so:

mySecureRandom.setSeed(mySecureRandom.generateSeed(someInt));

so as to give a potential attacker something less than unlimited time to discover your key.

There's some great writeups about this consideration at the Justice League blog.

Upvotes: 18

Alex Miller
Alex Miller

Reputation: 70231

Once should be enough. My experience has also been that initializing SecureRandom type generators can sometimes be slow as well (due to how randomness is achieved), so you should take that into consideration.

Upvotes: 1

Nick Johnson
Nick Johnson

Reputation: 101149

I would not rely on SecureRandom to be anything other than a cryptographically secure PRNG. The complete quote that Gowri is using from the javadocs is:

Additionally, SecureRandom must produce non-deterministic output and therefore it is required that the seed material be unpredictable and that output of SecureRandom be cryptographically strong sequences as described in RFC 1750: Randomness Recommendations for Security.

It's less than clear from this what the real expectation is - RFC 1750 details the use of hardware to enhance random number generation, but the javadocs say "therefore it is required that the seed material be unpredictable", which would seem to contradict this.

The safest assumption to work on is that your implementation of SecureRandom is simply a cryptographically-secure PRNG, and therefore that your keys are no more secure than the random seed that you use. Thus, initializing a new SecureRandom with a new (unique, truly random) seed for each key would be the safest bet.

Upvotes: 3

Mitch Wheat
Mitch Wheat

Reputation: 300699

Initialize a static instance and use it for all key pairs. It won't be any more or less random.

Upvotes: 6

Related Questions