CBC模式的位翻轉攻擊
為了執行位翻轉攻擊，使用 XOR 修改前一個塊。這導致更改的明文。但是，現在前一個塊的密文被改變了，因此會導致格式無效。我是正確的還是我錯過了什麼？
例如，假設我有以下明文
name=jcconvenant;photo=picture.jpg;admin=false;colour=red;和對應的密文
c26a5697689463d662f540e55e2a1ecef9c5df20133dfe49d6d3c369679a95ff4f4c5a490f530b2a2f25db40da64f1e9302724ce61b9a435e23f4d600252a143假設我們進行一點翻轉攻擊，得到如下密文
c26a5697689463d662f540e55e2a1ecef9c5df20133dfe49d6c1d07071c495ff4f4c5a490f530b2a2f25db40da64f1e9302724ce61b9a435e23f4d600252a143然後生成的明文仍然看起來已損壞。
¶ä╚° h8ì│►Nƒz│Ioé¤ßkü2KÀQiý4I@pg;admin=true;;colour=red;有沒有辦法在獲得有效明文的同時執行位翻轉？
位翻轉攻擊
CBC模式下的解密過程為 $$ \begin{align} P_1 =& Dec_k(C_1) \oplus IV\ P_i =& Dec_k(C_i) \oplus C_{i-1},;; 1 < i \leq nb, \end{align} $$ 在哪裡 $ nb $ 是塊的數量。
如果知道目標字節的位置，那麼就可以修改前一個密文塊中對應的密文位置。例如; 如果修改密文中的一個字節 $ C_{i-1} $ ， 然後 $ P_i $ 將改變一個塊，因為 $ C_{i-1} $ 只影響明文 $ P_i $ 經過 $ \oplus $ . 我們可以在下圖中直覺地看到；
$ \color{red}{\textbf{Red case:}} $ 一個密文字節 $ C_2 $ 修改的。這會影響下一個明文塊中的相應字節 $ P_3 $ 和對應的全明文塊 $ P_2 $ 它與修改後的密文具有相同的索引，即垃圾。這可以看作是有錯誤。
$ \color{ForestGreen}{\textbf{Green case:}} $ 一個 $ \text{IV} $ 字節被修改（綠色），這僅影響第一個明文中的相應字節 $ P_1 $ . 如果目標明文在第一個塊中，則不會留下痕跡。
一個例子
考慮這個簡單的消息
msg = "Buy 1000 lots of waffles"現在攻擊者截獲了消息和現在的預設結構，並希望將其修改為
msg = "Buy 5000 lots of waffles"這是範例 Python 程式碼（完整程式碼在這裡）；
def bitFlip( pos, bit, data): raw = b64decode(data) list1 = list(raw) list1[pos] = chr(ord(list1[pos])^bit) raw = ''.join(list1) return b64encode(raw)通過呼叫
ctx = bitFlip(4,4,ctx)將 1 更改為 5。這是綠色案例攻擊，不會留下垃圾塊。某些文件格式（例如 PDF）可以承受紅色大小寫攻擊。
一點理論
CBC模式加密只能提供Ind-CPA安全。CPA 安全不能抵抗主動攻擊，例如 CCA（有關詳細資訊，請參閱這篇文章Indnotions）。因此，主動攻擊者可以代表他們修改純 CBC 密文。如果消息格式已知，這可能會造成破壞性影響，尤其是當重要部分位於第一個塊中時。
緩解措施
由於數據沒有完整性和身份驗證，因此攻擊是可能的。如果必須使用 CBC 模式，則可以使用MAC或HMAC來防止這種情況，例如 AES-CBC-HMAC。
在其他情況下，最好使用現代加密方案。具有相關數據 (AEAD)的經過身份驗證的加密，可提供機密性、完整性和真實性。範例是 AES-GCM 和 ChaCha20-Poly1305。在 TLS 1.3. 中，CCM、GCM和poly1305是標準化的認證加密模式。
上面還有其他替代方案，例如 AES-GCM-SIV，它旨在抵抗基於 CTR 的加密（所有 TLS 1.3 都具有）的（隨機數，密鑰）對恢復問題，以及使用 192 位隨機數來減少的 xChaha20-Poly1305碰撞的機率變成非常低的機率。
