隨機會話密鑰 + 可預測 IV
我在玩具 Diffie-Hellman 通信方案中使用 Blowfish。為每個連接生成隨機會話密鑰。
在這種情況下，我可以簡單地將一個空數組提供給 IV 對嗎？相同的明文永遠不會用相同的密鑰流加密。
如果您使用 CBC 模式並且您的通信協議看起來像 SSL，那麼您可能會遇到問題。在 SSL 3.0 和 TLS 1.0 中，每條記錄的 IV是前一個 IV 的最後一個塊；這意味著既可以在流中註入他自己的一些數據並觀察結果的攻擊者可能知道下一條記錄的 IV 並相應地選擇他的數據。這是BEAST 攻擊的基礎：當客戶端是 Web 瀏覽器時，攻擊上下文被證明是真實的。
一般來說，一個體面的通信協議應該同時提供機密性和完整性，這意味著您的數據應該使用MAC。眾所周知，將對稱加密和 MAC 正確結合起來很棘手，一個好的方法是使用GCM或EAX之類的加密模式來完成這兩項工作。這裡的一個好點是這兩種模式不需要隨機 IV，只需要非重複 IV。
這導致了一個通信協議，其中初始密鑰交換（例如，您的 Diffie-Hellman）產生一個初始共享密鑰，該密鑰擴展為兩個對稱密鑰，用於兩個通信方向（這種“擴展”可以像散列一樣簡單SHA-256 的初始共享密鑰，並將 256 位結果分成兩半 128 位）。然後客戶端和伺服器都向對方發送一系列“消息”，使用每個消息的序列號作為 IV（從客戶端到伺服器的第一條消息使用值 1 作為 IV，第二條消息使用值 2，依此類推） .
請注意，GCM 和 EAX 依賴於 AES。您可以將它們調整為任何 128 位分組密碼。現在不建議使用具有 64 位塊的分組密碼，如 3DES 或 Blowfish，因為許多加密模式的安全性在加密時往往會崩潰 $ 2^{n/2} $ 具有相同鍵的塊，當塊具有大小時 $ n $ 位。對於 64 位塊，門檻值約為 30 GB，這不算多。
如果您的協議是單記錄的（在密鑰交換之後，每一方都發送一條消息，該消息被一次性加密，避免任何類似 BEAST 的問題），那麼固定的 IV 是可以接受的，因為密鑰將用於單一加密執行。但是，從共享的 DH 秘密中導出用於加密的對稱密鑰和IV同樣可以接受；這就是 SSL/TLS 所做的（或至少在 TLS-1.1 版本之前所做的）：參見標準，第 6.3 節。
為每個連接生成一個隨機會話密鑰是通常的方法。
即使您這樣做，您仍然需要滿足標準 IV 要求。
但是，如果您改為為每個要加密的明文生成一個隨機會話密鑰，
那麼您可以使用固定的 IV，例如將“空數組輸入 IV”所產生的任何結果。