IV需要鹽
我主要提到了這個問題。絕對在使用鹽的情況下，IV 可以為每個密鑰添加隨機化。但是在使用 IV 使用鹽的情況下不是多餘的嗎？（例如在 CBC 模式下使用 AES 引用 PBE。）
（這是因為在我的理解中，使用鹽會使使用彩虹表或喜歡對每種可能的鹽進行暴力破解是不可行的，並且 IV 將進一步為每條消息添加隨機化……但在使用的情況下IV 每條消息都會隨機化，所以彩虹表在不使用鹽的情況下也不可行。）
聽起來您正在使用基於密碼的密鑰派生函式，該函式接受可選的鹽輸入以將密碼片語轉換為加密密鑰，然後您可以使用該密鑰以分組密碼模式（或可能是其他類型的流密碼）加密消息) 需要一個 IV 或一個隨機數，並且您想知道是否有必要為 KDF 提供鹽，因為您正在使用唯一的 IV 加密每條消息。
一般來說，答案是“可能，但至少同時使用兩者不會有什麼壞處”。
IV 和 salt 確實有兩個完全不同的安全目標。IV 用作加密過程的一部分，其主要目的是允許安全地使用相同的密鑰來加密多條消息。* 如果使用相同的密鑰和 IV 來加密多條消息，檢查密文可以洩露一些關於明文的資訊。
（洩露的確切資訊取決於密碼模式：對於 CBC 和 CFB 模式，它包括消息共享的任何公共前綴的長度，以及可能有關第一個不同密碼塊的一些資訊；對於 CTR 和 OFB 模式，重用IV 洩露了完整消息的按位異或！）
另一方面，鹽用於密鑰派生過程，** 其主要目的是通過一方面確保具有相同密碼的兩個使用者獲勝來減緩某些類型的暴力密碼破解攻擊’最終不會得到相同的密鑰，另一方面，防止攻擊者提前預先計算密碼/密鑰組合。
（一些 KDF 也可能使用 salt 來允許從同一個密碼片語派生多個準獨立密鑰，而其他 KDF 有一個單獨的參數。類似地，一些密碼模式也可能對 IV 有額外的要求；例如， CBC 模式需要一個不僅獨特而且不可預測的 IV 來抵抗某些選擇明文攻擊。）
特別是，基於密碼的密鑰派生函式應該實現密鑰拉伸，即它應該故意佔用資源來計算以減緩暴力攻擊。在此過程中包含唯一的鹽很重要，因為它可以防止攻擊者通過同時針對多個使用者獲得顯著優勢。
如果沒有鹽，攻擊者只需為每個密碼執行一次緩慢的密鑰派生過程，然後針對每條擷取的消息快速測試生成的密鑰。對 KDF 進行加鹽會迫使攻擊者改為分別為每個使用者/消息重複緩慢的密鑰派生過程。 **IV 在這裡無濟於事，**因為它僅在加密步驟中應用，在緩慢的密鑰派生過程結束後。
IV 對這樣的暴力密碼猜測攻擊並沒有任何影響；正確使用 IV 可以防止的攻擊類型是基於重複使用相同密鑰和 IV 加密多個消息的明文恢復（不是密鑰恢復）攻擊，這可能會洩露有關這些消息的明文資訊。
請注意，如果您只使用 KDF 生成的每個密鑰加密單個消息，那麼您可以安全地使用固定 IV。 但是在這種情況下，你肯定需要在你的 KDF 中使用每條消息的鹽，以保證密鑰確實是唯一的。在任何情況下，即使在這種情況下不是絕對必要的，使用隨機唯一 IV 仍然是安全的預設選擇。
**附言。**無論如何，您確實應該使用經過身份驗證的加密模式而不是普通的 CBC 來防止主動篡改攻擊。在這些模式中，我想特別提一下SIV 模式（RFC 5297），它旨在提供額外的抵抗意外 IV 重用的能力。
*) 至少，我們在這裡討論的那種 IV 是這樣的。 更一般地說，術語“IV”實際上僅表示“初始化向量”，並用於各種算法，如雜湊函式，涉及迭代處理數據塊或“向量”。唉，在這一點上，術語可能太根深蒂固了，無法改變。
**) Salts 還用於基於密碼的身份驗證方案中的密碼散列。實際上，密碼雜湊和密鑰派生是非常相似的任務，因此算法和術語基本相同。
相關連結：