确定性地生成加密安全密钥和 IVEC

Question

背景

我正在设计一个系统，可以为静态 Web 内容的用户开发动态身份验证方案。其动机是预先生成大量生成复杂但敏感的 Web 内容，然后通过基于 cookie（嵌入可逆加密信息）的身份验证静态地提供这些内容，并由 Web 服务器单独强制执行。使用 AEAD 模式加密原语。

问题

我需要生成在一段时间内有效的 IVEC 和密钥，比如一周（当前有效的对）。并且过去的 IVEC/密钥的有效期为 2 周（历史有效），并且使用历史有效密钥加密的任何数据都将使用当前有效的 IVEC/KEY 重新加密。

我需要的是一个确定性的 CSPRNG，它是随机数和密码的种子，并且可以以索引方式生成 64 位或 128 位数字块。如果我使用自“1970 年 1 月 1 日”以来的几周作为我假设的 CSPRNG 的索引元素之一，我应该能够构建一个随着时间的推移自动更改密钥的系统。

我正在考虑的方法

现在我在 cryptopp 中没有看到这样的功能，或者我现在已经足够了解这些术语，并且由于 cryptopp 是最先进的加密库，所以我不知道有信心我会找到另一个。因此，如果我找不到那里的实现，我应该推出自己的实现。从连接的数据中生成静态字符串结构然后对其进行散列（如下所示）可以解决问题吗？

RIPEMD160(RandomPreGenerateFixedNonce:PassPhrase:UInt64SinceEpoch:128BitBlockIndexNumber);

注意：块编号将被分配并具有常规结构，因此例如对于 128 位摘要，块 0 的前 64 位将用于 ivec，所有元素 1 将用于 128 位密钥。

这是一种合理的方法（即加密安全）吗？

-- 编辑：发表接受评论 --

经过一番思考，我决定将我最初考虑的密码和随机数/盐合并到 16 字节（加密强）密钥中，并使用PKCS #5 中概述的技术用于派生多个基于时间的密钥。不需要盐，因为不使用密码。

Answer 1

有趣的问题。

首先，您的初始向量不必是密码学上强的随机量，但它们应该每条消息都是唯一的。 IV 实际上只是一种盐值，可确保使用相同密钥加密的类似消息在加密后不会看起来相似。您可以使用任何快速伪随机生成器来生成 IV，然后将其（最好是加密的）与加密数据一起发送。

当然，按键的强度应与您实际制造的一样强。

在我看来，您对包含随机数、密码和有效性数据的文本字符串进行散列的建议似乎非常合理——它与使用密码生成密钥的其他系统所做的工作大致一致。您应该散列更多次 - 而不是一次 - 以使密钥生成的计算成本昂贵（对于任何试图暴力破解密钥的人来说，这将是一个比您更大的问题）。

您可能还想查看 PKCS#5 中规定的密钥生成方案（例如，在 http://www.faqs.org/rfcs/rfc2898.html），它在 cryptopp 中作为 PasswordBasedKeyDerivationFunction 实现。该机制已被广泛使用，并且已知相当安全（请注意，PKCS#5 建议对密码数据进行哈希处理至少 1000 次）。您可以将有效期和索引数据附加到密码短语中，并按原样使用PasswordBasedKeyDerivationFunction。

您没有说明您建议使用哪种加密算法来加密数据，但我建议您应该选择广泛使用且已知安全的加密算法……特别是我建议您使用 AES。我还建议使用 SHA 摘要函数之一（可能作为 PasswordBasedKeyDerivationFunction 的输入）。 SHA-2 是最新的，但 SHA-1 足以用于密钥生成目的。

您也没有说明您要生成的密钥长度，但您应该知道密钥中的熵量取决于您使用的密码短语的长度，除非密码短语非常< /em> long 远小于理想情况下所需的密钥长度。

该方案中最薄弱的环节是密码短语本身，这总是会限制您可以实现的安全级别。只要你对数据加盐（就像你正在做的那样）并使密钥生成成本高昂以减缓暴力攻击，你应该没问题。

Answer 2

我需要的是一个确定性的 CSPRNG，它包含随机数和密码短语的种子，并且可以以索引方式生成 64 位或 128 位数字块。如果我使用自“1970 年 1 月 1 日”以来的几周作为我假设的 CSPRNG 的索引元素之一，我应该能够构建一个随着时间的推移自动更改密钥的系统。

好吧，我认为解决方案的一部分是使用非基于时间的生成器。这样，如果双方都以相同的种子开始，那么它们都会产生相同的随机流。您可以在此基础上添加“自 1970 年第 1 周以来的周数”逻辑。

为此，您可以使用 OFB_mode::Encryption。它可以用作生成器，因为 OF​​B 模式使用从 RandomNumberGenerator 派生的 AdditiveCipherTemplate。

事实上，Crpyto++ 使用 test.cpp 中的生成器，以便在出现故障时可以重现结果。以下是使用 OFB_mode::Encryption 的方法。它也适用于 CTR_Mode::Encryption：

SecByteBlock seed(32 + 16);
OS_GenerateRandomBlock(false, seed, seed.size());

for(unsigned int i = 0; i < 10; i++)
{
    OFB_Mode<AES>::Encryption prng;
    prng.SetKeyWithIV(seed, 32, seed + 32, 16);

    SecByteBlock t(16);
    prng.GenerateBlock(t, t.size());

    string s;
    HexEncoder hex(new StringSink(s));

    hex.Put(t, t.size());
    hex.MessageEnd();

    cout << "Random: " << s << endl;
}

对 OS_GenerateRandomBlock 的调用从 /dev/{u|s}random 获取字节并然后将其用作模拟共享种子。程序的每次运行都会有所不同。在程序的每次运行中，它都会打印类似于以下内容的内容：

$ ./cryptopp-test.exe
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD
Random: DF3D3F8E8A21C39C0871B375013AA2CD

还有另一个可用的生成器可以执行相同的操作，但它不是 Crypto++ 库的一部分。它称为 AES_RNG，基于 AES-256。它是一个仅标头的实现，您可以在 Crypto++ wiki 的 RandomNumberGenerator 下找到它。

另请参阅 Crypto++ wiki 上 RandomNumberGenerator 类的主题 再现性 。