PBKDF vs HKDF 相當長的密鑰
我正在開發一個帶有加密聊天的信使應用程序。
在應用程序的第一個版本中，我使用 PBKDF2（10000 次迭代，SHA1，隨機鹽）來擴展短使用者密碼並生成密鑰以加密（AES256）和簽名消息（HMAC）。
在應用程序的目前版本中，我生成一個隨機的 130 位密鑰並使用它而不是使用者密碼。我認為將 PBKDF2 與這樣的密鑰一起使用會產生一些成本。
我看到了改進目前方法的兩種可能方法：
- 繼續使用 PBKDF2 並將迭代次數減少到 1 或 10。
- 不要使用 PBKDF2 而是使用 HKDF。
每種方法的優點和缺點是什麼？還有其他選擇嗎？
你是對的：如果你的密鑰已經有足夠的熵來抵抗沒有它的蠻力攻擊，那麼就不需要密鑰拉伸。一個 128 位的密鑰空間應該足夠了。
AFAIK，HKDF 和單次迭代 PBKDF2 在實踐中沒有顯著差異。兩者都有效地實現了將輸入密鑰擴展到可能更長的派生密鑰序列的目標，其方式不允許從派生密鑰中有效地恢復原始輸入密鑰。
可以說，為此目的使用 HKDF 有點“整潔”，因為它已明確設計用於非基於密碼的密鑰派生，而使用迭代計數為 1 的 PBKDF2 正式超出其原始設計參數。但是，有幾種現有的方案，例如scrypt，確實以這種方式使用 PBKDF2，並且沒有明顯的結構原因說明以這種方式使用的 PBKDF2 不是安全的非密鑰拉伸 KDF。此外，如果您已經在使用 PBKDF2 進行基於密碼的密鑰派生，那麼實現第二個 KDF 可能會被視為不必要的複雜性（無論多麼輕微）。
就個人而言，我最喜歡的方法是，在確實需要密鑰拉伸和生成多個派生密鑰材料的雜湊輸出塊的情況下，使用混合 PBKDF2/HKDF — 也就是說，使用 PBKDF2（或另一種密鑰拉伸KDF）生成一個中間偽隨機密鑰（一個雜湊輸出塊大小），然後使用 HKDF-Expand 函式從中間 PRK 生成派生密鑰。這結合了 PBKDF2 和 HKDF 的最佳特性，並且被 RFC 5869 第 3.3 節隱式允許（如果已經有一個均勻分佈的偽隨機密鑰字元串，則可以跳過 HKDF 提取階段）。
使用這種方法可以讓您在統一框架內支持基於密碼和基於隨機密鑰的密鑰派生：
- 對於密碼輸入，使用具有適當高迭代次數的 PBKDF2 導出中間 PRK。
- 對於隨機密鑰輸入，使用 HKDF-Extract（或單次迭代的 PBKDF2）導出 PRK，或者直接使用輸入密鑰作為 PRK。
- 在任何一種情況下，使用 HKDF-Expand 從 PRK 派生實際的加密和 MAC 密鑰。
*附言。*只是出於好奇，我搜尋了我之前寫的提到 HKDF 和 PBKDF2的答案。我不認為這些問題中的任何一個與您的問題完全相同，但答案可能有些相關：