使用隨機 nonce 對 AES-CTR 進行多目標攻擊
128 位分組密碼容易受到多目標攻擊，其中攻擊者試圖攻擊一組密鑰而不是單個密鑰。一個簡單的例子：
- 生成密鑰 $ k_1, k_2, …,k_{2^{40}} $ .
- 選擇一個 128 位的消息塊 $ m $ 並提供 $ m $ 給攻擊者。
- 計算 $ E(k_1, m), E(k_2, m), …, E(k_{2^{40}}, m) $ 並將這些密文提供給攻擊者。
- 攻擊者可以計算 $ E(k, m) $ 用於各種鍵 $ k $ 找到與提供的密文之一匹配的密文。這將需要 $ 2^{87} $ 的評價 $ E $ 一般。
我感興趣的是這對 CTR 操作模式有什麼實際影響。攻擊者顯然需要一定數量的已知或受控明文才能獲得分組密碼輸出。更重要的是，這種攻擊依賴於在許多密鑰中提供相同明文塊的分組密碼。
CTR 模式將塊加密為 $ E(k, n | c) \oplus P $ ， 在哪裡 $ P $ 是明文塊， $ n $ 是隨機數和 $ c $ 是塊索引。確定性地生成隨機數的協議似乎容易受到這種攻擊。
我的問題：是否有可能使這種攻擊適用於使用 CTR 模式和隨機nonce 的協議？隨機化 nonce 能否成功保護 CTR 模式免受多目標攻擊？
攻擊者顯然需要一定數量的已知或受控明文才能獲得分組密碼輸出。
實際上，這不是什麼大問題。我們通常可以從真正的加密消息中獲得合理數量的已知明文。事實上，每條消息的已知明文不必相同，您也不必擁有完全已知的明文；明文中足夠數量的線性方程將起作用。
更重要的是，這種攻擊依賴於在許多密鑰中提供相同明文塊的分組密碼。
是的，這是關鍵。點擊率加密是：
$$ C = AES_k(n) \oplus P $$ 這種多目標攻擊通過評估（用於測試 $ k $ ) $ AES_k(n) $ 一次，然後使用它來並行檢查所有明文、密文對（例如，通過將該值與 $ C_i \oplus P_i $ 您已預編譯的值。
但是，這僅適用於每個明文/密文對具有相同的 $ n $ . 如果每個人使用不同的 $ n $ ，那麼你必須評估 $ AES_k(n) $ 分別針對每個明文/密文對；在這種情況下，您最好選擇一條消息，然後強制執行該消息。
這種保護並不是一個新穎的想法。對於 TLS 和 IPsec，GCM RFC 要求在 nonce 中包含 32 位隨機（實際上是 KDF 派生的）鹽，特別是為了阻止這種類型的攻擊。