為什麼 CTR 模式將明文異或到分組密碼的輸出中，而不是將明文異或到分組密碼的輸入中？

據我了解，CTR 模式本質上是將分組密碼轉換為流密碼，如下所示：

       _______________
      |       |       |
      | nonce |   i   |
      |_______|_______|
              |
       _______V_______
      |               |
      |  block cipher |
key -->|  (encryption) |
      |_______________|
              |
              V
plaintext --->(+)---> ciphertext

但是通過將其轉換為流密碼，必須非常小心不要重複使用 nonce。這樣做似乎更安全：

       _______________
      |       |       |
      | nonce |   i   |
      |_______|_______|
              |
plaintext --->(+)
              |
       _______V_______
      |               |
      |  block cipher |
key -->|  (encryption) |
      |_______________|
              |
              \---> ciphertext

雖然重複使用 nonce 仍然是不明智的，但如果以這種方式濫用它，其影響似乎不會那麼具有破壞性。我看到了一個主要缺點，那就是第一個公式只需要實現分組密碼的加密部分，而使用第二個公式，加密和解密都需要實現。

我的問題是：

1. 後一種操作模式有名稱嗎？
2. 後一種模式有什麼明顯的弱點嗎？
3. 第一種方式定義點擊率還有其他原因嗎？

1. 這種設計有一些嚴重的問題會妨礙它被標準化，所以它可能沒有名字。
2. 兩個明顯的主要缺陷如下：

• 如果明文遵循類似於塊計數器的模式，則塊密碼輸入可能會重複，從而暴露有關明文的資訊（與隨機數重用完全相同的問題，但每條消息可能發生多次，最後給出的範例）
• 長度不等於塊大小倍數的明文需要密文中包含的長度才能解密，因為解密需要完整的塊輸出，或者它們需要填充最後一個塊。

3. CTR 的結構具有您的範例所沒有的幾個理想屬性。它允許加密而無需填充或額外長度的數據來解密。它允許在明文可用之前對密碼流進行預計算，如果有足夠的可用記憶體並且消息明文以不規則的間隔可用，這可能意味著速度的巨大提升。CTR 也可以以高度並行的方式處理，如果不能立即使用明文作為輸入，則可能會減慢速度。

以下是重複塊的範例：

“這是一個簡單的測試，旨在探索如果我們加密會發生什麼這是一個沒有安全模式的測試”

塊 0 明文 = “這是一個測試 S”，塊 4 明文 = “這是一個測試 W”

在此範例中，對於此消息，塊 0 和 4 的塊密碼輸入將相同，無論隨機數如何，因為當與塊 4 的塊計數器異或時，“W”變為“S”。很多數據類型具有相似類型的重複資訊，只有很小的變化，例如圖像文件和可執行程序。對於潛在的明文恢復而言，這幾乎與歐洲央行一樣糟糕。

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