KDF 和 PBKDF 的軟體介面？

我正在從 RFC 5869實現 Krawczyk 和 Eronen HKDF 。從 Krawczyk 的原始論文中，他在Cryptographic Extraction and Key Derivation: The HKDF Scheme中確定了 KDF 的四個輸入。四個輸入是：

1. 基礎密鑰材料（秘密或種子）
2. 上下文資訊（綁定安全參數）
3. 公共鹽（可選，提供唯一性）
4. 派生密鑰的長度

我試圖調和 KDF（例如，用於基於 Diffie-Hellman 的方案）和 PBKDF（例如，用於將密碼消化成密鑰材料）之間的差異，以提供通用軟體界面。我認為區別在於：

• KDF 通常享有更高的熵種子，並且不使用迭代計數
• PBKDF 通常缺乏更高的熵種子，並使用迭代計數來幫助進行一些攻擊。有時他們使用目的字節，有時他們使用鹽等（目的字節似乎是上下文資訊的一種特殊化）。

將 PBKDF 添加到需求中，我認為列表變為：

1. 基礎密鑰材料（秘密或種子）
2. 上下文資訊（綁定安全參數）
3. 公共鹽（可選，提供唯一性）
4. 派生密鑰的長度（可選）
5. 迭代次數

我想確保以可擴展的方式很好地表示安全參數，這導致我提出兩個問題：

1. 說 PBKDF 是 KDF 的專業化是否公平？
2. 一個支持以上五個參數的軟體界面就夠了嗎？

（抱歉，我涉足軟體設計領域。我需要了解密碼學的人的幫助和專業知識，而不是

$$ purely $$軟體架構師）。

1. 說 PBKDF 是 KDF 的專業化是否公平？

當然。PBKDF 是一個 KDF，只是一個使用密碼/密碼作為熵源的 KDF。

OTOH，KBKDF（基於鍵的 KDF，如果你想這樣稱呼它）也是KDF 的一個特化。一個不同的專業化，這就是為什麼將它們視為一個單一的東西可能不是一個好主意。

2. 一個支持以上五個參數的軟體界面就夠了嗎？

缺少幾個常見參數：

1. 許多密碼散列函式都有第二個成本參數，指示將使用多少記憶體。（例如 scrypt，大多數來自目前正在執行的密碼雜湊競賽。）
2. 另一個比較常見的參數是辣椒。如果需要，您可以將其作為鹽的一部分包含在內，但是對於您的上下文資訊參數也是如此。

我也不認為您的參數，即使有上述添加，是定義這樣一個介面的最佳方式。

一方面，我認為不應該遺漏鹽，所以我不明白為什麼它應該是可選的。

另一方面，與密碼雜湊的使用方式相比，密鑰派生函式的正常使用方式存在顯著差異：

• 使用密鑰派生函式，您將需要一個特定大小的密鑰作為輸出。
• 使用密碼雜湊獲得一個不透明的返回值是很有用的，它可以作為唯一的附加參數傳遞給驗證常式：

verify(password, combined_hash)

（參見模組化加密格式。）

這樣迭代次數、鹽分等很容易與雜湊一起儲存，並且不同的雜湊可以有不同的參數，允許隨著攻擊者計算能力的增加，隨著時間的推移提升強度。

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