您是否应该使用带有或不带提供程序的SecureRandom.getInstance()？

Question

因此，我对密码学很陌生，我正在学习SecureRandom以及它调用带有或不带提供者的实现的所有方法。

当我查找一些站点的信息时，它说不要使用提供程序，因为如果提供程序过时或在系统中不可用，那么应用程序必须准备好处理异常。

然而，许多人说，使用提供程序可以规避选择像阻塞实现这样的糟糕实现的风险。

在Java文档中，我看到当您指定特定的提供者时--即使框架具有提供相同实现的更高优先级的提供者--它只会转到前面提到的提供程序以获得实现。不过，这听起来不太吸引人。

那么，您是否应该使用提供程序的getInstance()呢？哪种更好些呢？

Answer 1

这是一个本质上与加密API的信任有关的问题，并不是专门针对SecureRandom的。我仍将围绕SecureRandom制定我的答案，因为它是一个很好的示例。

你更信任谁，那些编写API代码并将其记录在案的人，还是网络上的随机评论？开发人员做出了选择，所以您不必做出选择，因为他们比他们的API的普通用户更了解风险和问题。为了实现API的灵活性，开发人员允许用户覆盖他们的实现决策。只有当你肯定比他们更了解的时候，你才应该这么做。

SecureRandom试图使用可用的最佳源代码，通常是由操作系统提供的。由于您没有做出更好选择的专门知识(否则您就不必问您的问题)，您应该使用默认的方法，并适当地处理异常(例如，拒绝提供不安全的服务)。

Answer 2

不要指定提供程序。绝对不要硬编码提供程序。如果它不存在，那么您的应用程序将根本不运行。

配置提供程序的唯一原因是，提供程序的特定实现的随机值提供了默认实现没有显示的属性。即使这样，您也应该问自己，是否应该在其他地方也使用这种特定的服务，在这种情况下，您可以将随机提供程序放在列表的首位。

有些地方不可能做到这一点:一个值得注意的问题可能是RNG的速度。例如，我可以想象，您希望使用智能卡或TPM的随机数生成器来生成长寿密钥。这种随机数生成器不是您想要用于每个TLS会话的东西。现在，这将是同时指定算法和提供者的一个很好的例子。

即使这样，我也会使用(签名)配置文件输入选择，而不是在源代码中硬编码解决方案。仅仅为了硬件更新而重新编译解决方案通常不被认为是OK的(尤其是在Java /字节码方面)。

请注意，软件算法是确定性的，需要由操作系统播撒。因此，如果系统提供种子时随机数生成器阻塞，则无法避免阻塞。因此，您可以选择任何类型的软件提供商，但您仍然会阻止系统，直到更多的熵变得可用。