<p>As others say, the secure RNG can have limited throughput.  To mitigate this
you can either stretch that secure randomness by seeding a CPRNG, or you can
try to optimise your usage of the bitstream.</p>

<p>To shuffle a pack of cards, for example, you need only 226 bits, but a naive
algorithm (calling <code>nextInt(n)</code> for each card) will likely use 1600 or 3200
bits, wasting 85% of your entropy and making you seven times more susceptible
to delays.</p>

<p>For this situation I think the <a href="http://mathforum.org/library/drmath/view/65653.html" rel="nofollow">Doctor Jacques
method</a> would be appropriate.</p>

<p>To go with that, here's some performance analysis against progressively more
costly entropy sources (also contains code):</p>

<p><a href="http://arxiv.org/pdf/1012.4290.pdf" rel="nofollow">Bit recycling for scaling random number generators</a></p>

<p>I would lean towards efficient usage rather than stretching, because I think it
would be a lot easier to prove the fairness of an efficient consumer of a
trustworthy entropy stream, than to prove the fairness of any drawing method
with a well-seeded PRNG.</p>

<hr>

<p><strong>EDIT<sup>2</sup>:</strong>
I don't really know Java, but I put this together:</p>

<pre><code>public class MySecureRandom extends java.security.SecureRandom {
    private long m = 1;
    private long r = 0;

    @Override
    public final int nextInt(int n) {
        while (true) {
            if (m &lt; 0x80000000L) {
                m &lt;&lt;= 32;
                r &lt;&lt;= 32;
                r += (long)next(32) - Integer.MIN_VALUE;
            }
            long q = m / n;
            if (r &lt; n * q) {
                int x = (int)(r % n);
                m = q;
                r /= n;
                return x;
            }
            m -= n * q;
            r -= n * q;
        }
    }
}
</code></pre>

<p>This does away with the greedy default uniform [0,n-1] generator and replaces it with a modified Doctor Jacques version.  Timing a card-shuffle range of values shows almost a 6x speed-up over the <code>SecureRandom.nextInt(n)</code>.</p>

<p>My previous version of this code (only 2x speed-up) assumed that <code>SecureRandom.next(b)</code> was efficient, but it turns out that call was discarding entropy and dragging the whole loop down.  This version manages its own chunking.</p>
Is java.secure.random a sufficient choice for gambling industry?
<p>Java provides an cryptographically secure random number generator in the package java.secure.random. </p>

<p>Is it possible to use this number generator if I consider things like seeding and cyclic re-instantiation of the RNG? Or can I use the number generator 'as it is'?</p>

<p>Has anyone experience with this generator?</p>

<p><strong>EDIT</strong>: the requirements are:</p>

<p>a) Be statistically independent</p>

<p>b) Be fairly distributed (within statistically expected bounds) over their range</p>

<p>c) Pass various recognized statistical tests</p>

<p>d) Be cryptographically strong.</p>