將 ECB 和 CTR 塊操作模式結合起來是否可行？
ECB 和 CTR 塊模式都比其他塊模式具有優勢。它們都支持並行加密和解密以及隨機讀/寫。然而兩者都有主要缺點：（我假設 AES 塊大小）
- ECB 為相同的 16 字節明文生成重複模式
- ECB 可以在 16 字節塊中進行混洗，這會導致明文以相同的方式混洗
- CTR 將明文異或到加密的隨機數+計數器。如果 nonce 和 key 被重複使用，您可以創建一個 XOR 密鑰來加密/解密任何使用相同密鑰和 nonce 的 AES-CTR 加密文件/消息（這主要在您可以加密數據但不讀取密鑰/nonce 時有用從硬體 AES 回來）
結合 ECB 和 CTR（首先用 ECB 加密數據，然後用 CTR 加密密文）仍然允許並行加密/解密和隨機讀/寫。然而，如果你打亂塊，改變位置的塊會被完全破壞。另外，您不能只使用相同的密鑰/隨機數創建一個異或密鑰，因為數據仍然使用不同的密鑰加密。這也將使密鑰大小加倍。
我的問題是：這種阻塞模式存在嗎？像這樣的塊模式的主要問題是什麼？
編輯：兩種加密的密鑰不同，這使得 ECB 和計數器加密不太可能產生相同的密文。
然而，如果你打亂塊，改變位置的塊會被完全破壞。
這可能是真的，但如果你這樣做，你必須定義你所取得的成就。您在這裡嘗試做的是更改加密模式的錯誤傳播。然而，歐洲央行的錯誤傳播非常有限；它只延伸到一個街區。如果您更改一位，則整個輸出都會更改。但是，如果您的輸入可能有大量可能的值，則不會檢測到更改。現在你可以引入一個嬰兒床，一個已知的明文，但你仍然必須創建另一個通道，例如一個加密安全的散列，以保護所有塊只使用一個嬰兒床。
錯誤傳播曾經是分組密碼的一個重要主題。然而，如今我們傾向於依賴 CRC 或類似 PAR2 的方案來避免損壞（密文）文本。而且我們傾向於依賴消息認證程式碼 (MAC) 來創建加密安全的認證標籤。最後，我們有諸如 OCB 和 GCM 之類的方案，它們提供 1 到 1.5 次通過身份驗證的加密，使您的方案效率相當低。
另外，您不能只使用相同的密鑰/隨機數創建一個異或密鑰，因為數據仍然使用不同的密鑰加密。這也將使密鑰大小加倍。
由於遇到中間攻擊，加密兩次通常不會使密鑰大小加倍。你必須證明這是事實。
但考慮到效率低下且只有部分錯誤傳播和無效身份驗證，我認為您不必深入研究該主題。
我同意@Maarten Bodewes 的回答，尤其是事實上
由於遇到中間攻擊，加密兩次通常不會使密鑰大小加倍。你必須證明這是事實。
但是，如果我正確理解了這個問題，您希望將 ECB 與 CTR 結合起來，因為您擔心重複的隨機數 + 密鑰對會破壞 CTR 的安全保證。因此，我認為您的目標類似於nonce misuse-resistance。粗略地說，即使以錯誤的方式使用，防誤操作的操作模式也能達到不錯的安全水平（例如 SIV
$$ 1 $$）。CTR 模式的可證明安全保證（參見$$ 2 $$例如）如果一個隨機數在同一個鍵下重複，則不成立。
像這樣的塊模式的主要問題是什麼？
正如您所提到的，當多個塊在同一密鑰下加密時，ECB 模式下的加密變得確定性。從安全的角度來看，這確實很糟糕，因為這意味著對手將辨識出相同的明文是否被多次加密。此外，ECB 對於選擇明文的對手並不安全，即它沒有達到 IND-CPA。我假設您的目標是 IND-CPA，因為這是僅保密方案應該實現的常見安全符號。只要中間計數器值不重疊，使用 nonce 作為初始化向量 (IV) 的 CTR 模式就可以實現 IND-CPA。在任何 IND-CPA 安全加密方案中，IV 用於隨機化加密方案。
現在，如果您擔心 CTR 使用不正確並且重複了一對 (nonce,key)，我不知道 ECB 應該如何幫助您，因為 ECB 無法承受主動選擇明文攻擊。無論如何，您建議的操作模式不會“加倍”安全級別。
$$ 1 $$: Rogaway, P. 和 Shrimpton, T. (2007)。SIV 操作模式，用於確定性認證加密（密鑰包裝）和防誤用的基於 nonce 的認證加密。http://www.cs.ucdavis.edu/~rogaway/papers/siv.pdf $$ 2 $$貝拉爾、米希爾等人。“對稱加密的具體安全處理。” http://web.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf