15

我读过，一般来说，SecureRandom 的某些实现可能会产生真正的随机数。

特别是，Android 文档说

此类的实例将使用内部熵源生成初始种子，例如/dev/urandom

但这是否意味着它将产生真正的随机数（即，而不是伪随机数）？

如果我SecureRandom以这种方式在Android中使用......

SecureRandom sr = new SecureRandom();

...每当我打电话时，我会得到一个真正随机的输出sr.nextBoolean()吗？

或者，如果我每次都通过这样做来获得输出，那么输出是否可能更多（或更少？）随机： new SecureRandom().nextBoolean()？

4

3 回答 3

5

“真”和“伪随机”随机数对不同的人意味着很多不同的东西。最好避免这些。

/dev/urandom得到了一个不好的代表，因为人们不理解它和/dev/random（比你预期的要少得多）之间的差异。

如果您问播种是否/dev/urandom会损害将SecureRandom其用于加密目的的适用性，答案是响亮的“不”。

如果你有时间，你可能想阅读我关于整个问题的文章。

于 2014-09-13T09:55:33.923 回答
1

根据Android 开发者文档：

(SecureRandom) 符合 FIPS 140-2，加密模块的安全要求，第 4.9.1 节中指定的统计随机数生成器测试

然而，同样的警告也适用于 Android 和 Java：

许多 SecureRandom 实现采用伪随机数生成器 (PRNG) 的形式，这意味着它们使用确定性算法从真正的随机种子生成伪随机序列。其他实现可能会产生真正的随机数，而其他实现可能会使用这两种技术的组合。

所以，简短的回答是：这取决于实施，但如果您对 FIPS 140-2 没问题，那么 SecureRandom 在法律上足以满足您的目的。

于 2019-04-10T07:41:23.460 回答
0

关键的答案是/dev/urandom，按照linux 内核的定义，保证不会阻塞。重点是在生成足够的熵的同时不让用户停滞不前。如果 android 文档说他们正在使用/dev/urandom初始化，并且内核中没有足够的熵来提供随机数，那么内核将退回到伪随机算法。

根据内核文档，/dev/urandom除了“长寿命 [加密] 密钥”之外，几乎所有目的都被认为是足够的。鉴于您对预期用途的描述，我怀疑 androidSecureRandom将被证明是随机的，足以满足您的目的。

于 2014-09-13T00:10:36.503 回答