HKDF-扩展最大输出长度

Question

我试图使用HKDF-Expand从一个伪随机的512位密钥中派生出大量的键控材料(> 64 to )。

现在，根据HKDF RFC，在对HKDF-Expand的单个调用中可以导出的最大键值是255 * HashLength，在我的示例中，它将是输出的255 * 64 = 16,320字节(因为我使用的是SHA512)。

但是，对于我来说，16,320字节的输出是不够的。但我想我可以通过两条路线使用HKDF-Expand生成这些数据：

1. 使用对HKDF-Expand的多次调用来派生大小为16,320字节的多个键，并将它们连接在一起。从理论上讲，这并不违反RFC规范，因为我相信RFC允许您多次调用HKDF-Expand，生成最多每个time.的255 * HashLength字节数据，我将为导出的每个键设置一个32位计数器，并将其传递到HKDF time.的Info参数中。这样我就不会继续得到同样的材料了。
2. 我注意到在HKDF-Expand的实现中，我将使用.NET和RFC，它指定在8位计数器变量之前将Info缓冲区添加到哈希中。这意味着，如果对Info使用某种整数计数器是可以的，那么理论上应该可以修改8位计数器，该计数器目前正在将HKDF-Expand's输出长度限制在更大的范围内，比如32位计数器。因此，我可以生成更多的关键数据。

我的3个问题如下：

1. 对Info参数使用整数计数器到HKDF-Expand可以吗？我相信任何具体的应用程序和无关的PRK是可以的，对吗？
2. 利用Info参数从512位PRK中生成这么多键控数据可以吗？
3. 如果问题2实际上没有问题，那么这不意味着它应该可以改变8位计数器比目前限制HKDF-Expand's输出长度为一个更大的计数器，如32位？

谢谢你在这里的任何时间！我仍然是一个大密码新手，所以我道歉，如果这些是愚蠢的问题！

此外，如果有人想知道，512位PRK来自PBKDF2，我需要64 do的键控数据更多的是为了体验的目的，看看我能用香港国防军做些什么。

Answer 1

1. 是的，没有已知的坏的互动。
2. 有点。没有已知的攻击HKDF仅仅是因为使用同样的PRK来生成大量的关键材料。如果已经存在64 GB的问题，那么我认为应该在RFC中明确地解决这个问题。如果你只需要一个确定的关键材料流，那么你也可以考虑，例如，使用CTR_DRBG从NISTSP800-90A的AES。这也可以使用CPU中的AES管道(可能是向量化的)来在优化的实现中以高速的速度产生输出。与HMAC-SHA-512相比，从AES生成大密钥流的密码分析可能也更多.在需要重新启动之前，NIST将该构造限制为对2^{48}位的2^{19}调用。我还应该指出，64 GB的关键材料流看起来很不寻常。
3. 我猜这是RFC中的8位，因为输出长度255*Hashlen字节似乎足以满足实际使用的键/种子。根据“Info”的长度，较大的计数器可能会在散列函数中花费额外的压缩函数调用。注意，在Krawczyk的论文(第4.2节) https://eprint.iacr.org/2010/264.pdf中没有将计数器指定为8位。