HKDF-擴展最大輸出長度

我正在嘗試HKDF-Expand從偽隨機 512 位密鑰中獲取大量密鑰材料（> 64GB）。

現在根據HKDF RFC，您可以在一次呼叫中獲得的最大密鑰材料數量HKDF-Expand是255 * HashLength，在我的情況下是255 * 64 = 16,320輸出字節數（因為我使用的是 SHA512）。

但是，16,320 字節的輸出對我來說還不夠。但我想我可以通過 2 條路線生成這些數據HKDF-Expand：

1. 使用多個呼叫來HKDF-Expand派生大小為 16,320 字節的多個鍵並將它們連接在一起。這在理論上不會違反 RFC 規範，因為我相信 RFC 允許您HKDF-Expand多次呼叫255 * HashLength，每次生成最多字節的數據。

為此，我將為導出的每個密鑰設置一個 32 位計數器，並將其傳遞給InfoHKDF-Expand 的參數。這樣我就不會繼續推導出相同的材料。 2. 我注意到在HKDF-Expand我將使用的.NET和 RFC 的實現中，它指定Info緩衝區將被添加到 8 位計數器變數之前的散列中。這意味著如果使用某種整數計數器Info是可以的，那麼理論上應該可以將目前限制HKDF-Expand輸出長度的 8 位計數器修改為更大的值，例如 32 位計數器。因此，我可以生成更多的關鍵數據。

我的3個問題如下：

1. 可以為Info參數使用整數計數器HKDF-Expand嗎？我相信任何特定於應用程序且與 PRK 無關的內容都可以嗎？
2. 是否可以通過利用Info參數從 512 位 PRK 生成如此多的鍵控數據？
3. 如果問題 2 實際上沒問題，那麼這是否意味著應該可以將 8 位計數器更改為目前將HKDF-Expand’ 的輸出長度限制為更大的計數器，例如 32 位？

感謝您在這裡的任何時間！我仍然是密碼學的大菜鳥，所以如果這些是愚蠢的問題，我深表歉意！

PS 另外，如果有人想知道，512 位 PRK 來自 PBKDF2，而我需要的 64GB 密鑰數據更多地用於實驗目的，看看我可以用 HKDF 做什麼。

1. 是的，沒有已知的不良相互作用。
2. 有點兒。僅使用相同的 PRK 生成大量密鑰材料，就沒有對 HKDF 的已知攻擊。如果 64 GB 已經存在問題，那麼我認為應該在 RFC 中明確解決。如果您只需要確定性密鑰材料流，那麼您還可以考慮使用 NIST SP 800-90A 中的 AES 的 CTR_DRBG。這也可以使用 CPU 中的（可能是矢量化的）AES 管道在優化的實現中以高速產生輸出。據推測，從 AES 生成大型密鑰流的密碼分析比 HMAC-SHA-512 還要多。NIST 將該構造限制為 $ 2^{48} $ 的電話 $ 2^{19} $ 需要重新播種之前的位。我還應該評論說，64 GB 的關鍵材料流似乎很不尋常。
3. 我猜它在 RFC 中是 8 位，因為輸出長度 255*Hashlen 字節對於實踐中使用的密鑰/種子似乎已經足夠了。較大的計數器可能會在散列函式中花費額外的壓縮函式呼叫，具體取決於“資訊”的長度。請注意，在 Krawczyk 的論文（第 4.2 節） https://eprint.iacr.org/2010/264.pdf中，計數器未指定為 8 位。

引用自：https://crypto.stackexchange.com/questions/101935