java - 安全随机 : thread safe without contention and still cryptographically secure?

Question

通过论坛阅读似乎 SecureRandom 是线程安全的，但由于争用它在多线程系统中挣扎，请参阅 Is SecureRandom thread safe? .初始化一个新的 SecureRandom 也是一项昂贵的操作。提高性能的一个建议是使用 ThreadLocalRandom .

所以我改变了我的代码:

SecureRandom randomSecureRandom = SecureRandom.getInstance("SHA1PRNG");

到:

private final ThreadLocalRandom randomThreadLocal = ThreadLocalRandom.current();

我做了一些测试 - 运行 100 次以加密 10000 个字符串值，我可以看到明显的改进。

**With ThreadLocalRandom**
Thread #18New encryption service took on average: 66.44ms.
Thread #17New encryption service took on average: 64.79ms.
Thread #14New encryption service took on average: 70.77ms.
Thread #13New encryption service took on average: 72.33ms.
Thread #19New encryption service took on average: 73.42ms.
Thread #15New encryption service took on average: 74.21ms.
Thread #11New encryption service took on average: 76.79ms.
Thread #16New encryption service took on average: 78.72ms.
Thread #12New encryption service took on average: 78.95ms.
Thread #20New encryption service took on average: 78.99ms.

**With SecureRandom**
Thread #19New encryption service took on average: 87.26ms.
Thread #18New encryption service took on average: 93.65ms.
Thread #13New encryption service took on average: 93.1ms.
Thread #15New encryption service took on average: 95.81ms.
Thread #16New encryption service took on average: 96.9ms.
Thread #11New encryption service took on average: 97.0ms.
Thread #20New encryption service took on average: 94.93ms.
Thread #17New encryption service took on average: 96.63ms.
Thread #12New encryption service took on average: 97.41ms.
Thread #14New encryption service took on average: 99.08ms.

似乎我确实提高了这里的速度，但是我降低了安全性，因为 ThreadLocalRandom 似乎不是加密安全的:

 * <p>Instances of {@code ThreadLocalRandom} are not cryptographically
 * secure.  Consider instead using {@link java.security.SecureRandom}
 * in security-sensitive applications

我的问题是 - 有没有办法创建密码安全的随机数，它是线程安全的并且在多线程系统中表现良好？

还有一个问题涉及此主题，但答案是建议从 SecureRandom -> ThreadLocalRandom 进行相同的转换，这不是加密安全的，请参阅 Minimizing SecureRandom performance problems in multithreaded environment? .

Answer 1

SecureRandom 实现比 ThreadLocalRandom 慢得多。这与线程安全无关。

ThreadLocalRandom生成下一个随机数的算法涉及的数学运算很少，容易破解。事实上，单个 nextLong 操作返回的结果足以确定该生成器生成的所有 future 和过去的数字，请参阅 https://jazzy.id.au/2010/09/20/cracking_random_number_generators_part_1.html如果您对细节感兴趣。

另一方面，您选择的提供商的 SecureRandom 使用 SHA1 生成随机数。 SHA1 的计算成本很高，因此性能比 ThreadLocalRandom 差。这是设计使然 - 计算复杂性是使 SHA1 难以逆转和种子难以猜测的因素之一。

为了比较性能，我使用两个生成器在单个线程中生成了 100M 个随机数。 ThreadLocalRandom 耗时 95 毫秒，SecureRandom 耗时 41 秒。

编辑以解决线程性能问题:

您可以为每个线程创建一个 SecureRandom 实例。它将在第一次使用从静态(共享/同步)实例中获取的数据时进行初始化，但后续操作将是线程本地的。我使用共享和专用 SecureRandom 实例测量了 4 个线程的性能。每个线程产生100M随机数；专用实例耗时 30 秒，共享实例耗时 1 分 54 秒。