java.secure.random是否是赌博行业的足够选择？

Java在包java.secure.random中提供了加密安全的随机数生成器.

如果考虑RNG的播种和循环重新实例化,是否可以使用此数字生成器？还是可以按原样使用数字生成器？

有没有人体验过这个发电机？

编辑：要求是：

a)统计上独立

b)在其范围内公平分配(在统计上预期的范围内)

c)通过各种公认的统计测试

d)加密强度高.

解决方法:

就像其他人说的那样,安全的RNG可能具有有限的吞吐量.为了减轻这种情况
您可以通过播种CPRNG来扩展安全性随机性,也可以
尝试优化您对比特流的使用.

例如,要洗牌,只需要226位,但是天真
算法(每张卡调用nextInt(n))可能会使用1600或3200
比特,浪费了85％的熵并使您的敏感度提高了7倍
拖延.

对于这种情况,我认为Doctor Jacques
method将是合适的.

为此,下面是一些性能分析,以逐步
昂贵的熵源(还包含代码)：

Bit recycling for scaling random number generators

我倾向于有效使用而不是扩展,因为我认为
证明一个有效消费者的公平性会容易得多
值得信赖的熵流,而不是证明任何绘图方法的公平性
播种良好的PRNG.

EDIT2：
我不太了解Java,但是我将其组合在一起：

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 < 0x80000000L) {
                m <<= 32;
                r <<= 32;
                r += (long)next(32) - Integer.MIN_VALUE;
            }
            long q = m / n;
            if (r < n * q) {
                int x = (int)(r % n);
                m = q;
                r /= n;
                return x;
            }
            m -= n * q;
            r -= n * q;
        }
    }
}

这消除了贪婪的默认统一[0,n-1]生成器,并用修改后的Doctor Jacques版本替换了它.对卡混洗值范围进行定时显示,与SecureRandom.nextInt(n)相比,速度几乎提高了6倍.

我以前的代码版本(仅2倍加速)假定SecureRandom.next(b)是有效的,但事实证明,该调用正在丢弃熵并将整个循环拖到下面.此版本管理其自己的分块.

标签：java,algorithm,random,prng
来源： https://codeday.me/bug/20191010/1888417.html