KDF 與流密碼
我想知道為什麼有人可以使用流密碼來代替使用 HKDF（或任何 KDF）。
似乎流密碼總是單向的，而 KDF 可能不是（例如，參見 AES 或 DES 密鑰調度）。因此，如果您使用 KDF 來導出公共值和私有值，則使用 KDF 可能會很危險（儘管看起來最常用的 HKDF 被構造為單向的。這很好，因為它在 TLS 中用於導出私有值密鑰以及公共 IV）。
我可以看到為什麼 KDF 可能更適合的兩個原因：
- 它需要一個 SALT 參數。所以你可以用同一個鍵多次使用它，但是通過改變參數你會得到不同的輸出。如果你要用流密碼來做到這一點，你需要記住一個狀態。
- 它有一個工作因素。因此，使用 SALT，您可以將其用作密碼散列函式。但後來我們有點偏離了軌道。
但是這兩件事似乎並不特定於 KDF ……
似乎流密碼總是單向的，而 KDF 可能不是（例如，參見 AES 或 DES 密鑰調度）。
KDF 與 DES 或 AES 密鑰調度無關。密鑰時間表是分組密碼的內部功能，它們並非設計為 KDF。KDF 當然應該是單向函式。
從 SP-800 SP 108 第 7.1 章，加密強度：
密鑰推導函式的安全強度是通過將 KDF 的輸出與相同長度的真正均勻分佈的位串區分開所需的工作量來衡量的，假設密鑰推導密鑰， $ K_I $
$$ ed: the input keying material $$, 是 KDF 的唯一未知輸入。
因此，如果您使用 KDF 來導出公共值和私有值，那麼使用 KDF 可能會很危險。
KDF 的輸出應該與隨機無法區分，因此該陳述是錯誤的 - 這可能與您的陳述有關，即它們可能不是一種方式。
它需要一個 SALT 參數。所以你可以用同一個鍵多次使用它，但是通過改變參數你會得到不同的輸出。如果你要用流密碼來做到這一點，你需要記住一個狀態。
鹽用於進一步加強 HKDF 的安全證明。在 SP 108 中，它們可以是 Context 的一部分，然後稱為 Nonce（並且，鑑於鹽足夠大，隨機鹽在計算意義上是唯一的）。隨機 IV 會對流密碼做同樣的事情。
基於密鑰的 KDF不需要鹽，因為輸入密鑰材料應提供足夠的熵。
但是我認為您正在混淆基於密鑰的 KDF，例如 HKDF 和基於密碼的 KDF，例如 PBKDF - 見下文。
它有一個工作因素。因此，使用 SALT，您可以將其用作密碼散列函式。但後來我們有點偏離了軌道。
僅當輸入材料不夠強時才需要功因數。這基本上是基於密碼的 KDF 的情況，例如 PBKDF2、bcrypt、scrypt 和 Argon2。功因數用於加強輸入鍵控材料（在某種程度上）。
計數器模式加密不明確包含任何輸入標籤、鹽或上下文的方式。KDF 構造使這些明確。
關於輸出，KDF 可以與不同的資訊（標籤/上下文）一起使用，使用相同的輸入密鑰材料生成不同的密鑰。如果您將這樣的功能集成到例如 HSM（安全令牌）中，這一點很重要，您希望將輸出作為密鑰保留在令牌中（而不是在軟體中手動拆分）。
最後，許多 KDF 不僅包含擴展函式以生成足夠的輸出密鑰材料，它們還包含提取功能以壓縮輸入密鑰材料中的熵。許多流密碼需要與隨機和/或特定長度無法區分的密鑰。所以他們不提供提取功能。
KDF 是從 PRF 建構的；PRF 提供了為 KDF 創建證明所需的安全性。實際上，計數器模式通常用於 KDF，但它們使用 PRF 代替 PRP，例如分組密碼（當然 PRF 可以由分組密碼本身創建）。所以最後許多 KDF 確實輸出了一個偽隨機位流。