XTS 與 CBC 模式（帶擴散器）相比有什麼優勢？
與帶有擴散器的 CBC 相比，我在理解 AES-XTS 的“優勢”方面存在一些問題。
我讀過一些關於FileVault的文章，在本文中他們提到了 XTS 和 CBC（帶擴散器）的兩種操作模式以及 XTS 的優點。
兩種模式加密數據單元的方式幾乎相同。對於 CBC，扇區號以某種方式用於建構 IV，對於 XTS，有一個“調整值”，其中還包括（不知何故）塊偏移量，因此每個數據塊都可以獨立加密（在加密硬碟驅動器時有意義/分區）。我無法真正看到 XTS 的優勢。
現在，他們寫了以下關於 XTS 的內容：
與 CBC 中的 AES 等替代方案相比，它有幾個優點：不需要初始化向量（調整密鑰可以從塊編號中導出）；每個塊的加密方式不同（因為調整值會不同）；與 AES-CBC 不同的是，AES-XTS 可以防止攻擊者通過對每個 AES 輸入進行異或運算來更改數據單元中的一個特定位，並使用加密調整的不同移位版本。
也許他們只是將 XTS 與 CBC（不帶擴散器）進行比較……如果是這樣，有人知道 XTS 的任何優勢嗎？
有人可以解釋第二個優勢嗎：“AES-XTS 可以防止攻擊者通過對每個 AES 輸入進行異或運算來更改數據單元中的一個特定位，並使用加密調整的不同移位版本。”？
**XTS 與未擴散的 CBC。**這裡的問題是延展性。XTS 和 CBC 都可以防止攻擊者了解有關加密數據的資訊。然而，沒有一個人能完全成功地阻止攻擊者篡改加密數據。
但是，可以說篡改（未擴散的）CBC 密文比篡改 XTS 密文更容易。假設攻擊者碰巧知道一些消息說
“等等等等，給愛麗絲400美元……等等等等”。
如果此消息使用 CBC 加密，則攻擊者可以篡改密文，使其現在可以解密為
“等等等等！^%@^^ 給愛麗絲800美元等等等等”
400美元變成了800 美元。這就是您引用的“AES-XTS 防止攻擊者更改數據單元中的一個特定位”所指的內容。這裡寫!^%@^^表示之前的16字節塊一旦解密就會變成亂碼，而這個亂碼將超出攻擊者的控制範圍。
另一方面，使用 XTS 可以防止這種攻擊。攻擊者可以通過將任何 16 字節塊變成隨機亂碼來破壞消息，但他將無法像在 CBC 範例中那樣擁有相同程度的控制。
但微軟還是決定不使用 XTS。原因是破壞 16 字節塊的能力仍然可能具有破壞性。以下是連結的紙質 dchest 的引述：
例如，可能有一個配置文件（或系統資料庫項），其值在設置為 0 時會在作業系統中創建一個安全漏洞。磁碟上的設置類似於“enableSomeSecuritySetting = 1”。如果值的開頭落在 16 字節的邊界上並且攻擊者隨機化明文值，則有 $ 2^{16} $ 明文的前兩個字節可能是 0x30 0x00，這是一個對 ASCII 值“0”進行編碼的字元串。
（這句話指的是 LRW 可調整密碼，但 XTS 中使用的 XEX 可調整密碼也有同樣的問題）。
**添加擴散器。**使用擴散器是 Microsft 解決此問題的方法。這裡的想法是在加密之前將明文“混合”起來，這樣攻擊者就無法將400美元更改為 800美元——干預部分密文將改變幾乎整個明文，而不僅僅是其中的一小部分。
這聽起來不錯，但有一個問題：沒有人真正知道微軟的擴散器是否真的安全。據我所知，它尚未收到密碼學家發表的任何正式分析。這意味著您應該對依賴它持懷疑態度。微軟承認這一點：
不利的一面是，擴散器是一種未經證實的新算法，這不可避免地會引發問題。如果沒有對算法進行廣泛的公眾審查和分析，對其安全性存在合理的懷疑。人們不願意相信新算法。那麼為什麼我們還是選擇了這個選項呢？在我們的最終分析中，我們認為這是我們產品的更好選擇。相對於替代方案的性能提升非常重要，足以超過新擴散器算法的缺點。時間會證明我們是否做出了正確的選擇。
底線。 XTS 的延展性低於未擴散的 CBC。然而，CBC+Diffuser 的延展性可能不如 XTS，至少在實際用途上是這樣。
一個重要的旁白。 CBC 和 XTS 的設計都不是不可延展的。確保密文不被篡改是一個單獨的問題，應該通過使用消息驗證碼 (MAC)，例如 HMAC-SHA256 來解決。MAC 通常不用於全盤加密算法的原因是 (1) 性能問題和 (2) 使用 MAC 需要使用密文儲存額外資訊，這使得透明地添加它有點棘手。
MAC 和擴散器之間的中間立場是使用寬塊加密模式，例如 CMC、EME 或 HEH。您可以將這些視為具有“內置”擴散器，這使得它們不可延展。與微軟的擴散器不同，這些算法具有正式的安全定義和經過同行評審的數學證明。在 AES 是安全的假設下，它們是安全的。由於 (1) 性能問題和 (2) 專利，Microsoft 選擇不使用這些。