結合 CTR 和 ECB 模式防止攻擊
在Reusing AES-CTR Keys and IVs for File Encryption中，OP 詢問複合加密方案$$ C_i = E_K\left(P_i \oplus E_K\left(IV + i\right)\right) $$這基本上只是一個點擊率跟隨歐洲央行。
現在，雖然他們的意圖是將其用於磁碟加密（其中 IV 只是磁碟上塊的唯一（但已知）位置），但由於磁碟加密理論中攻擊者的攻擊能力，這種方法具有某些弱點. 但是，我想知道這種 CTR-then-ECB 是否有顯著優勢，除了磁碟加密上下文之外- 例如加密數據庫中的數據。
具體來說，
(IV/nonce + counter)如果攻擊者知道任何其他塊的明文也使用該(IV/nonce + counter). 不僅是一個(IV/nonce + counter)塊，而且屬於這些消息的任何“附近”塊也是如此（由於計數器重疊！）。
IV+counter但是，如果我們使用 CTR-then-ECB 進行加密，那麼攻擊者只有在使用相同加密並且還包含相同密文的情況下才會知道塊的明文。相比之下，僅 CTR 加密方案的攻擊者只需要匹配（IV + counter到已知塊），而僅 CBC 加密方案的攻擊者只需要匹配密文（到已知塊）。但這是一個顯著的優勢，還是這裡涉及的機率如此之小——尤其是如果使用隨機IV 時——CTR-then-ECB 無法提供任何真正的好處？（例如，使用 AES）
有幾個問題浮現在腦海：
- 這是一個雙通道方案，計算量很大；
- 相同塊的洩漏是不必要的，有些方案只洩漏完全相同的明文；
- ECB 模式需要填充，因此會產生一些成本。
現在您可以爭辯說 1. 在目前電腦上不是問題。但是，如果沒有任何方案可以呈現相同的屬性而不需要雙通道，那麼這將是一個很好的論點。
至於 2，有一些方案，例如 Format Preserving Encryption，除了完全相同的明文外，不會洩漏任何資訊。FPE 在實現方面通常相當昂貴（另一方面，對於大型二進製文件而言，不必儲存 IV 通常不是問題，因為它們通常具有可變大小）。另一種選擇是對索引執行塊加密並將其用作 CBC 模式的不可預測的 IV（如果您不喜歡填充成本，可能會竊取密文）。已經提到了現有的磁碟加密常式，例如 XTS 和 ESSIV。
至於3，ECB模式的密文竊取（CTS）當然可以實現，但它絕對不利於實現的容易性，這將是相對於其他方案的主要好處（ECB通常在例如SQL和CTR中可用）使用 ECB 實現相對簡單，儘管我絕對不喜歡在 SQL 中這樣做）。
最後，如果您有空間放置身份驗證標籤，則可以使用 SIV 模式（例如 AES-GCM-SIV）來消除對顯式 IV 的需求。如果您對兩者都有空間，那麼當然只有一個通用的 AES-GCM 是有意義的。
總而言之，我認為 - 雖然該方案有優點 - 有更好的選擇 - 最好是內置到數據庫引擎中的選項。