我读过，一般来说，SecureRandom的某些实现可能会产生真正的随机数。
特别是，Android文档说
此类的实例将使用内部熵源生成初始种子，例如
/dev/urandom
但这是否意味着它将产生真正的随机数（即，而不是伪随机数）？
如果我以这种方式在Android中使用...SecureRandom
SecureRandom sr = new SecureRandom();
...每当我调用时，我都会得到一个真正的随机输出吗？sr.nextBoolean()
或者，如果我每次都通过执行此操作来获取输出，则输出是否可能更随机（或更少？）：？new SecureRandom().nextBoolean()
“真”和“伪随机”随机数对不同的人来说意味着很多不同的东西。最好避免这些。
/dev/urandom得到了一个糟糕的代表，因为人们不了解它和（比你预期的要少得多的差异）。/dev/random
如果你问种子设定是否会损害将其用于加密目的的适用性，答案是一个响亮的“不”。/dev/urandomSecureRandom
如果你有一些时间，你可能想读一下我关于整个问题的文章。
（SecureRandom） 符合 FIPS 140-2 加密模块的安全要求，第 4.9.1 节中指定的统计随机数生成器测试
但是，同样的警告适用于Android和Java：
许多 SecureRandom 实现采用伪随机数生成器 （PRNG） 的形式，这意味着它们使用确定性算法从真正的随机种子生成伪随机序列。其他实现可能会产生真正的随机数，而其他实现可能会结合使用这两种技术。
因此，简短的答案是：这取决于实现，但是如果您同意FIPS 140-2，那么SecureRandom在法律上足以满足您的目的。
