这段随机数生成代码为什么这么写？

随机基础上再随机…
其实直接 new SecureRandom().nextInt() 就行了
因为种子一样随机的序列也是一样的，所以外面这一层 Random

@chendy #1 所以外面这一层 Random 没用了…

种子足够随机

@Ediacaran 原来这块代码种子的随机数位数也要更大些

@chendy 我现在是没想通它这个加层种子是想干啥，而且一个是 Random ，一个又是 Secure 的

总得给个种子吧，至于种子来源其实无所谓

常用的当前时间做种子理论上来说确实有被攻击的可能，所以这样写算是更安全的写法
不过实际上我觉得这人是想的有点多，除非是纯客户端程序在本地包个虚拟机强行改时间，不然的话用服务器当前时间戳作为随机数种子我觉得没啥问题

@jaredyam 通常的想法是 Random 要比 SecureRandom 性能高，SecureRandom 比 Random 更安全，这样用应该类似 https 的设计，用高安全性的 RSA 来传递密钥，然后用高性能的对称算法来执行加密过，基本都是这种设计思路

我推测是希望获得安全的随机数，但又希望减少来自 SecureRandom 的阻塞。

但如果说要评价写得好不好，应该在完成设计目标的前提下，考察随机性和必要性。即 SecureRandom().nextInt() 是否带来了足够的墒、new Random()的函数是不是安全的。以及可不可以直接使用 SecureRandom().nextInt()。

@sunny352787 所以你是说这个过程没问题是吧。

> 总得给个种子吧

这句话可以再解释下吗？和直接 Random.nextInt()有什么区别呢？也是出于安全的考虑？

SecureRandom 应该是用系统的安全随机数，Random 应该是纯算法的伪随机数。
个人感觉这么做，如果后面是从 random 对象中取多个随机数的话，会降低安全性。如果只取一次问题不大。

@jaredyam 另外，SecureRandom 本身在 Linux 等系统下使用的是操作系统的熵计算，也就是真随机数，但熵源不足的情况下会造成阻塞

SecureRandom 的默认参数所使用的种子可能来自于（ Posix 上）/dev/random 。而 /dev/random 是个有限的真随机序列，其内容来自于对机器硬件数据的采集。比如网卡的噪音、温度传感器、鼠标键盘动作等。

通过 SecureRandom 得到一个普通伪随机生成器 Random 的初始 seed ，可以有效地得到一个不可预测的随机序列。

@jaredyam 过程没问题，而且确实比用时间做种子更安全

大部分的语言的默认随机数生成器的实现都是需要设置一个种子的，不然默认种子为 0 ，也就是每次启动程序随机出来的序列都是一模一样的
大部分随机数生成算法就是一个迭代公式，用上一个结果计算下一个随机数，那么第一个数从哪来呢？就是你给的种子呗

random.nextInt();只一次，不如 new SecureRandom().nextInt()

random.nextInt();有限次，挺好

random.nextInt();很多次，看实际情况判断

虽然还没人问，但我推荐阅读一下 /dev/urandom 和 /dev/random 的文章，好像和前几年那些 Linux 书本不同，现在即使在加密场景下，也推荐使用 /dev/urandom ，说是已经足够安全了，又不会阻塞。

@CEBBCAT https://unix.stackexchange.com/questions/324209/when-to-use-dev-random-vs-dev-urandom
https://www.2uo.de/myths-about-urandom/

https://metebalci.com/blog/everything-about-javas-securerandom/ 可以看看这个，使用 random 看你对安全性的要求，里面有一个破解程序，只需要知道连续两个随机数，很快就能算出 seed 了，这时候使用 securerandom 作为 seed 与否并不不能保证安全的。

@zankard 不是连续的随机数，应该也可以运算，就是计算量就更大了。

不搞密码学应用 不用考虑这些问题

在座诸位 99.999999%用随机数的场景都只是需要一个随机一点的值来实现逻辑，而不是基于随机性进行安全化

这是对的。SecureRandom 应该是使用系统熵的真随机。使用这个作为伪随机的种子能够做到更好的效果。
因为在分布式 /多实例场景下，使用时间作为种子也很容易得到初冲突。

c++11 后也是这样的，参考 https://learn.microsoft.com/zh-tw/cpp/standard-library/random?view=msvc-170 最后一个实例
go 也有使用 crypto/rand 设置 math/rand 种子的用法

主要原因是真随机的获取非常慢。不适合在业务场景下使用。这种方式能够兼得随机性与速度的最好效果（甚至可以在多线程场景下分线程创建以避免锁开支）

@kkhaike #20 单论 Golang 来说，crypto/rand 的速度没有非常慢，大概是 math/rand 的一半。同样是读取 4KB 随机字节，crypto 花费 7.5us ，math 花费 3.3us 。

goos: darwin
goarch: arm64
BenchmarkRandRead4KB-8 356580 3335 ns/op
BenchmarkCryptoRead4KB-8 158610 7540 ns/op

https://gist.github.com/Zhang-Siyang/cb10162e8f98e87041201d15aea89088

seed 相同的 Random 产生的序列也是相同的

```java
public static void main(String[] args) {
Random random1 = new Random();
random1.setSeed(1L);
Random random2 = new Random();
random2.setSeed(1L);
for (int i = 0; i < 3; i++) {
System.out.println("random 1 - " + random1.nextInt());
System.out.println("random 2 - " + random2.nextInt());
}
}
```

```shell
random 1 - -1155869325
random 2 - -1155869325

random 1 - 431529176
random 2 - 431529176

random 1 - 1761283695
random 2 - 1761283695
```

把 seed 改成随机数可以避免这个现象

这实际上就是 /dev/urandom 的随机数生成方式，用 securerandom 做种子，然后跑纯靠计算的随机数算法

#23 @wangyu17455 https://www.2uo.de/myths-about-urandom/ 早已指出（机翻）：

/dev/urandom 是一个伪随机数生成器，一个 PRNG ，而 /dev/random 是一个“真”随机数生成器。

事实： /dev/urandom 和 /dev/random 都使用完全相同的 CSPRNG （一种加密安全的伪随机数生成器）。它们仅在极少数方面有所不同，与“真正的”随机性无关。

/dev/random 无疑是密码学的更好选择。即使 /dev/urandom 相对安全，也没有理由选择后者。

---
因此，要明确一件事：/dev/random 和 /dev/urandom 都由同一个 CSPRNG 提供。根据一些估计，只有当它们各自的池耗尽熵时的行为不同：/dev/random 阻塞，而 /dev/urandom 没有。

从 Linux 4.8 开始
在 Linux 4.8 中，/dev/urandom 和 /dev/random 之间的等效性被放弃了。现在 /dev/urandom 输出不是来自熵池，而是直接来自 CSPRNG 。

/dev/random 无疑是密码学的更好选择。即使 /dev/urandom 相对安全，也没有理由选择后者。

事实： /dev/random 有一个非常讨厌的问题：它会阻塞。

但这很好！/dev/random 给出的随机性与其池中的熵一样多。/dev/urandom 会给你不安全的随机数，即使它早已耗尽熵。

事实：不。即使不考虑可用性和随后的用户操纵等问题，熵“耗尽”的问题也是一个稻草人。大约 256 位的熵足以在很长很长一段时间内获得计算上安全的数字。

我说的是 真随机 的获取非常慢，因为涉及到操作系统要主动将熵值填入熵池，这个是很缓慢的。

golang 的 crypt/rand 在某些系统下并不是纯正的真随机（纯真随机应该类似于 /dev/random 一样会在熵池被掏空时阻塞），golang 在不同的操作系统下的实现
// On Linux, FreeBSD, Dragonfly and Solaris, Reader uses getrandom(2) if
// available, /dev/urandom otherwise.
// On OpenBSD and macOS, Reader uses getentropy(2).
// On other Unix-like systems, Reader reads from /dev/urandom.
// On Windows systems, Reader uses the RtlGenRandom API.

1. getrandom(flags==0), 相当于 /dev/random ，https://github.com/torvalds/linux/blob/d9fc1511728c15df49ff18e49a494d00f78b7cd4/drivers/char/random.c#L1343-L1350 ，默认会阻塞等待熵值
2. getentropy ，https://support.apple.com/zh-cn/guide/security/seca0c73a75b/web ， 使用 Fortuna 算法，安全度很高的伪随机并使用熵源初始化，无阻塞
3. RtlGenRandom ，https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom ， 文档上就说是伪随机
4. /dev/urandom ，不会阻塞，会在熵值耗尽使用 crng_fast_key_erasure 获得伪随机结果（ chacha 加密结果的一部分） https://github.com/torvalds/linux/blob/d9fc1511728c15df49ff18e49a494d00f78b7cd4/drivers/char/random.c#L336-L341

另外真随机是完全无规律的随机，所以只适合用作密码学相关以及设置伪随机的种子，在业务场景下，希望获得 均匀分布、正态分布 等特性的随机数需要对应的伪随机配合，所以 业务场景 真随机种子 + 伪随机算法 就是最优解没有之一

@CEBBCAT 上面忘了 at 。。。不好意思