為什麼我不應該使用 ECB 加密？
我正在使用 Java 生成加密字元串，並在建構時收到此警告：
不應使用 ECB 加密模式
所以我想知道為什麼我不應該使用歐洲央行以及我可以使用什麼？
為什麼我不應該使用 ECB 加密？
不使用ECB 模式加密的主要原因是它在語義上不安全——也就是說，僅僅觀察 ECB 加密的密文可能會洩漏有關明文的資訊（甚至超出其長度，所有接受任意長明文的加密方案都會在一定程度上洩漏）。
具體來說，ECB 模式的問題在於，使用 ECB 模式加密相同的明文塊（8 或 16 字節，或者底層密碼的塊大小有多大）總是產生相同的密文塊。這可以讓攻擊者：
- 檢測兩個 ECB 加密的消息是否相同；
- 檢測兩個 ECB 加密的消息是否共享一個公共前綴；
- 檢測兩個 ECB 加密的消息是否共享其他公共子字元串，只要這些子字元串在塊邊界對齊；或者
- 檢測單個 ECB 加密消息是否（以及在何處）包含重複數據（例如長時間執行的空格或空字節、重複的標頭欄位或文本中巧合重複的片語）。
在 Wikipedia 上有一個很好的圖形展示了這個弱點，其中使用 ECB 模式和語義安全的密碼模式（例如 CBC、CTR、CFB 或 OFB）對相同的（原始的、未壓縮的）圖像進行加密：
雖然這種情況有些人為（通常不會像這樣加密原始圖像），但它很好地展示了 ECB 模式的問題：輸入圖像中的重複區域導致加密輸出中的重複模式，因此許多大規模特徵儘管加密，圖像仍可辨識。在現實世界中，攻擊基於 ECB 的加密方案的密碼分析者更有可能在密文的十六進制轉儲中尋找此類模式，但原理是相同的。
如本答案所述，2013 Adobe 密碼數據庫洩露給出了 ECB 加密的這種弱點導致現實世界數據洩露的實際案例。在這裡，導致洩漏嚴重性的一個因素是，Adobe 沒有正確散列它們，而是使用 ECB 模式加密了密碼。這使攻擊者可以快速定位多個帳戶共享的密碼，或與其他密碼共享一個公共前綴（如password1和password2），並揭示每個密碼的大致長度。
ECB 加密模式還有其他弱點，例如它具有高度可塑性：由於每個明文塊都是單獨加密的，因此攻擊者可以通過將先前觀察到的密文中的塊拼湊在一起來輕鬆生成新的有效密文。
但是，只有在沒有消息驗證碼的情況下使用 ECB 加密時，延展性才是一個問題，並且在這種情況下，所有其他未經驗證的加密模式（例如前面提到的 CBC、CTR、CFB 和OFB。因此，它不能真正被視為 ECB 模式的特定弱點，即使在使用 ECB 模式時它確實往往是一個額外的問題。
我應該改用什麼？
您應該使用任何經過身份驗證的加密模式，例如GCM、EAX或OCB。
就個人而言，對於短消息，我更喜歡SIV 模式（RFC 5279），它提供了額外的防誤用層。（如果不小心使用相同的 IV / nonce 來加密多條消息，許多其他加密模式將破壞得相當嚴重。SIV 模式在這種情況下保留其所有安全屬性，除了洩露加密消息是否相同。）
您還可以使用任何傳統的語義安全加密模式（例如CBC或CTR ），並結合使用Encrypt-then-MAC構造的消息身份驗證程式碼（例如HMAC） 。（也就是說，您應該首先加密消息，然後計算密文的 MAC，並將其附加到密文中。）只要您確保在嘗試解密消息之前驗證 MAC，此構造將保護您免受這些模式對主動（選擇密文）攻擊的各種漏洞。
對於需要能夠修改部分密文而不重新加密所有數據的磁碟加密或類似應用程序，您應該使用為此目的設計的密碼模式，例如XTS。請注意，此類模式通常缺乏對主動攻擊的抵抗力，並且可能具有其他弱點，在使用它們之前應了解這些弱點。如果可能，它們應該與某種形式的完整性保護相結合，例如雜湊樹上的 MAC 。
