将PRNG用于流密码而不是专用算法

Question

我知道，可以使用一些确定性的PRNG (如HASH_DRBG或CTR_DRBG)和好的密钥作为种子来构建流密码。

相对于通用的PRNG，使用专用的流密码算法(如Salsa20或RC4在过时之前)有什么好处？

Answer 1

我在python模块中使用HMAC-DRBG作为备份，当没有安装“真正的”密码包时。python 2标准库提供密码散列和HMAC，但没有加密原语。

与AES-CTR/ChaCha相比，HMAC-DRBG的优势在于，它比在纯python中实现“真实”设计要简单得多，而且速度也更快。这是因为密码调用的实质是用C执行的，并且是通过python发送的--在C中执行的对sha512的两个调用比在纯python中运行的AES +操作模式要简单和快速得多。

此外，如果您已经在使用HMAC-DRBG，那么创建一个支持经过身份验证的额外数据的认证方案只需要进行少量的修改。

虽然它显然不是最理想的设置，当然也不适合生产使用，但在没有其他可用的情况下，它可以作为一种可怜的加密算法使用。由于这不是一种官方规定或证明的加密数据的技术，如果你使用这种技术，密码专家可能会对你指手画脚，特别是如果有一天它会导致问题的话。

它也会相对缓慢。问题是散列被设计成在很短的时间内吃掉大量的输入数据。它们不一定能在很短的时间内产生大量的输出数据(虽然使用了sha-3和运行模式，但这一点可以说不再是真的；我假设您没有sha-3和它提供的操作模式，否则您将使用它)。

如果您有其他选择，您可能应该使用它们-使用替代(HMAC-DRBG流密码)，而不是真正的交易(即，AES-CTR)，如果后者是可用的，这不是一个明智的决定。

Answer 2

我将给出使用PRNG / DRBG的缺点，而不是给出目的构建流密码的优点(毕竟，在流密码的用例中使用的是PRNG )：

• 实现细节(包括重新播种)在系统之间可能有所不同(如果DRBG被很好地定义和测试的话，这就不太可能了，但是由于它们被设计用来检索给定一些熵的随机数，所以你永远不知道)；
• 通常从系统中检索确定性流密码。这意味着它们可能会被重新种植。你可能会说，这主要是他们不同于流密码的主要原因。
• PRNG通常包含额外的反措施，以使状态与输入(种子材料)和输出脱钩，使它们变慢；
• PRNG的密码通常比流密码更复杂(代码大小、指令数量)。它们确实经常是由类似于流密码的构造(比如您提到的CTR_DRBG )创建的；
• PRNG没有为这种功能进行定义，这使得实现和代码维护变得更加复杂(例如，考虑到使用PRNG作为流密码绝对违反的最小惊讶原则)；
• PRNG通常不包含诸如缓冲、最后的XOR操作等实现细节；您可能必须包装一个DRBG来创建与流密码操作相同的加密/解密体验(例如，在Java中，您不能简单地添加一个Cipher而不实现和签名一个提供程序)。

Answer 3

我认为，如果我们改进算法的术语/分类，将重点放在需求而不是机制上，这个问题的答案就会更加清晰。特别是，“随机”数字的密码用法往往可分为两类：

1. 需要确定性价值的应用程序，这是对手无法预测的，但诚实的各方必须能够预测。
2. 需要非确定性值的应用程序，对手是无法预测的，但诚实的人也不需要预测。

类别1是伪随机生成器。第二类通常不被识别或被混淆地标记--这是一个目标，可以通过真正的随机生成器、伪随机生成器来实现，也可以在实践中通过将真正的随机抽样和伪随机生成相结合的算法来实现。主要的例子是操作系统的随机数生成器，它定期收集随机事件定时数据，以刷新伪随机生成器的状态。

现在，NIST是为#2类设计的算法。Salsa20和RC4是为#1设计的。流密码加密是一个需要确定性的#1类应用程序--为了解密Alice的消息，Bob必须确定地重建Alice生成的相同的密钥流。

您可以使用DRBG加密，但它们只是有一些与加密无关的多余步骤。而DRBG的构造方式，如果你仔细研究它，就会发现--DRBG通常包括某种形式的流密码作为一个组件，以及附加的内容，这样应用程序就可以用真正的随机样本来不确定地扰乱它的状态。