加密RNG输出

Question

在以下前提下：

• 我需要生成多个对称密钥；
• 我不能确定本地系统RNG的质量；
• 我已经有了一个强键K(通过其他方法/其他方法生成)。

用K加密系统RNG的输出(或对其进行某种派生)以增强生成的密钥是否有意义。更广泛地说，我能用K来加强RNG的输出吗？

澄清：

长度-假设K的熵是128位。键数-多个，但不多(几个或几十个，不是更多)。

第二次编辑：

更多的澄清和评论：

持久存储(并且是安全的，只要整个系统不受损害)是可用的，因此可以实现顺序IV。

我开始怀疑RNG可能是片状的，而系统还没有被破坏，但最初我认为RNG的质量不是黑白的，因为它很容易提供K，生成的密钥可以得到加强。

顺便说一下，我可以提供256位K，所以我真的可以用它作为一个PRNG的种子，而忘记所有其他。无论如何，对K的来源的妥协是完全下降的，所以这看起来是一个简单的选择。

Answer 1

如果您不信任系统RNG，甚至不要使用它，而是要信任K。

• 使用K作为安全PRNG的种子，然后从该RNG中生成密钥。(例如，ChaCha。不是RC4，因为它是过时和不安全的，但是其他安全流密码可以工作。)
• 或者使用K和一个键派生函数。如果您不需要遵循标准，那么使用HMAC和K作为它的关键。每次您需要一个长达512位的对称密钥，增加一个计数器，HMAC计数器值，然后从输出中获取您需要的多少位。

为什么？

您可以加密RNG的输出。对称密钥加密被认为是产生密文，这是无法区别于一个统一的随机比特源。加密随机或伪随机序列并不比对一些简单的非重复序列(如计数器)进行加密更好。

但是，您可以通过重用非mess、使用太小的块大小、使用糟糕的算法或使用错误的实现来破坏加密。我说，如果您不信任系统RNG，就不要使用它，因为加密其输出最多等于我列出的替代方案。

如果您的系统RNG是有偏的，或者没有足够的熵，那么如果您使用一个(不够)随机的IV加密，那么您就会遇到现在重用的问题。如果您可以用确定性的算法来防止现在的重用，那么您也可以用安全的PRNG防止现在的重用，或者为我提到的HMAC结构维护一个计数器。

您应该能够信任操作系统的安全RNG。但是，如果你不能接触到一个，或者你知道它没有足够的能量，那么这就是使用其他东西的理由。

你不可能比操作系统所提供的更好的、不可预测的、非确定性的RNG。用户尝试的熵收集(非确定性) RNG算法没有一个良好的跟踪记录。

如果您有一个高熵密钥，一个安全的算法，以及防止当前重用的能力，那么PRNG/KDF输出将是很好的。

Answer 2

加密RNG输出是到Vista为止的数百万台Windows机器中使用的一种非常普遍的技术。微软的CryptGenRandom基本上是SHA-1(RC4)。因此，哈希函数加强了(现在)破碎的RC4算法。如果您的本地系统RNG很差，您也可以这样做，这样就可以散列很长的输出序列。相当于使用AES-128-ECB加密来自RNG的16字节组，使用K。但是很难量化RNG对这种防御技术的否定有多糟糕。显然，加密像兰杜这样简单的线性同余生成器是愚蠢的。它的国家内部规模严重不足，无法抵御野蛮的武力攻击。

这是另一种更安全的建筑：

您忽略RNG，并基于AES-128-ECB创建自己的密码安全同盟。有一个简单的状态计数器，您只需增加每128位输出周期。

有些人会争辩说，您应该在这样的关键产品中使用公共库函数，这有一些优点。但是，欧洲央行的AES风格非常简单，如果您可以编写一个16字节计数器(大约5行代码)，就不会出错(！)我会后悔的。

注1.这只会创建伪随机密钥。它们非常好，但没有真正随机的好。如果K被破坏，所有K的孩子都会根据Kerckhoff的原理被破坏。

注2.关于类似的进一步了解，请参见我需要哪些PRNG安全要求来生成密钥？。

Answer 3

如果正确实现，这是一个强有力的假设，这是安全的。使用秘密密钥加密某物的结果应该与随机加密的结果是无法区分的。“正确实现”包括侧通道电阻。为此使用K会增加通过诸如定时之类的侧通道泄漏K的风险。

但是，您在加密时会遇到问题:您需要为您的加密方案生成一个IV，并且您不信任RNG。例如，CBC模式已经失效(它需要一个统一的IV)。CTR模式是可以的，如果你能确保计数器不会重复(见下文)。

然而，在大多数情况下，您将什么都得不到。攻击者很少能够危害系统RNG，但不会危及系统的其他部分。如果您担心系统RNG的熵太小，那么在混合中添加一个密钥并不一定能拯救您。K的问题是每次都是一样的。如果您的应用程序或设备在密钥生成期间重新启动，您会在重新启动时知道吗？你确定K不会在两种不同的设备上使用吗？如果这两个问题的答案都是肯定的，那么您可以使用K和一些值(不一定是秘密)一起使用，即使在重新启动之后也不会重复。这可以是一个RNG输出，如果您有可重写存储(如果没有可重写存储有限制的嵌入式设备，任何像样的OS都会为您做到这一点，所以如果您不在这样的嵌入式设备上，就不要费心使用系统RNG)。如果您没有可重写的存储，但您相信时间不会倒退，您可以使用时钟与K一起使用，如果没有，K不一定会拯救您，因为如果您的对手设法使RNG种子重复，则不会消除相同密钥的风险。

与其构建您自己的构造，我建议使用K加上一些固定的标签(以避免与K的其他用途发生意外冲突)作为PRNG的种子函数的额外输入。当然，也要用系统RNG来播撒PRNG。

再一次，如果您对系统RNG的安全性有严重的怀疑，并且您知道您的应用程序的使用方式不容易在重启后重复系统RNG状态，或者在多个设备之间使用相同的系统RNG，那么使用合适的系统RNG的风险大于您可能得到的好处。