我阅读了一些有关FileVault的内容，在本文中，他们提到了XTS和CBC的两种操作模式（带有扩散器） ）和XTS的优点。
两种模式几乎都以相同的方式加密数据单元。对于CBC，扇区号以某种方式用于构建IV，对于XTS，存在“调整值”，该值还包含（以某种方式）块偏移量，因此每个数据块都可以独立加密（在加密硬盘/分区）。我真的看不到XTS的优点。
现在，他们写了有关XTS的以下内容：不需要初始化向量（可以从块号中获得调整键）；每个块的加密方式不同（因为调整值将不同）；与AES-CBC不同，AES-XTS通过使用加密移位的不同移位版本对每个AES输入进行异或来防止攻击者更改数据单元中的特定位。
也许他们只是将XTS与CBC（不带扩散器）进行比较...如果是这样，有人知道XTS的任何优势吗？
有人可以解释第二个优势：“ AES-XTS阻止攻击者进行更改通过将每个AES输入与不同移位版本的加密调整值异或来对数据单元中的一个特定位进行加密。“？
#1 楼
XTS与未扩散的CBC。这里的问题是延展性。 XTS和CBC都可以阻止攻击者学习有关加密数据的信息。但是，没有人能完全成功地阻止攻击者篡改加密数据。但是，篡改（未扩散的）CBC密文比篡改XTS密文要容易得多。假设攻击者碰巧知道一些消息，说是
给Alice \ $ 400 ...等等blah“。
如果此消息使用CBC加密，则攻击者可以以如下方式篡改密文，使其立即解密为
“等等等等！^％@ ^^给Alice \ $ 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-混入部分密文将几乎更改整个明文，而不仅仅是其中的一小部分。
这听起来不错，但有一个陷阱：没有人真正知道Microsoft的扩散器是否确实安全。据我所知，它还没有收到来自密码学家的任何正式形式的分析。这意味着您应该对依赖它持怀疑态度。 Microsoft承认这一点：
不利的一面是，扩散器是一种未经验证的新算法，这不可避免地引起了疑问。没有广泛的公众审查和对算法的分析，人们对它的安全性持怀疑态度。人们不愿相信新算法。
为什么我们仍然选择此选项呢？在最终分析中，我们认为这是我们产品的更好选择。与替代方案相比，性能提升非常重要
，足以抵消新扩散器算法的缺点。时间会证明
我们是否做出了正确的选择。
最重要的是。
XTS的延展性不如未扩散的CBC。但是，至少出于实用目的，CBC + Diffuser的延展性可能不如XTS。
重要的一点。
CBC和XTS都不被设计为不可恶意移植的。确保密文不被篡改是一个单独的问题，应该使用诸如HMAC-SHA256之类的消息身份验证代码（MAC）来解决。 MAC通常不用于全盘加密算法的原因有（1）性能问题，（2）使用MAC需要存储带有密文的额外信息，这使得透明地添加它有点棘手。
MAC和扩散器之间的中间立场是使用宽块加密模式，例如CMC，EME或HEH。您可以将它们视为具有“内置”扩散器，从而使其不易损坏。与Microsoft的扩散器不同，这些算法具有正式的安全性定义和经过同行评审的数学证明。在AES是安全的假设下它们是安全的。 Microsoft选择不使用这些是因为（1）性能问题和（2）专利。
评论
$ \ begingroup $
在磁盘加密的情况下，简单的MAC不够好。您将需要具有经过身份验证的根的哈希树。
$ \ endgroup $
– CodesInChaos
2012年12月6日上午10:12
$ \ begingroup $
感谢您的出色回答！！！这使一切都清楚了... 5 *****
$ \ endgroup $
–tommynogger
2012年12月6日上午10:52
$ \ begingroup $
这可能行不通，但是通过使用不同的密码和/或不同的算法两次对相同的数据进行加密不会解决可延展性的问题吗？因此，为什么不使用未经验证的扩散器算法，而不是再次使用经过验证的AES？
$ \ endgroup $
– Yuriy Nakonechnyy
16 Mar 25 '16 at 10:58
$ \ begingroup $
@Yura这将取决于AES的使用方式（例如XTS，通常建立在AES之上）。如果您两次使用CTR-AES模式，结果的延展性也不会变差（在密文中翻转一位仍会在明文中翻转相应位）。如果您两次使用CBC-AES模式，您仍然可以进行我在答案中提到的相同攻击，但是不受控制的随机“垃圾”部分的长度将增加一倍。最后，无论如何，在安全的“宽块”模式下使用AES的速度大约与上述两种解决方案一样快。因此，也可以这样做。
$ \ endgroup $
–赛斯
16-4-17的6:16
$ \ begingroup $
更新：Windows 10确实提供了使用XTS模式的选项。更大或更糟的更新：在Windows 8中，Microsoft删除了扩散器。因此，Windows 8 bitlocker甚至没有扩散器。
$ \ endgroup $
–hft
17 Mar 17 '17 at 4:50
评论
什么是“扩散器”？ “部门号是什么”如何？您没有清楚地描述该方案。如果该算法是可预测的，则会导致缺陷，并且不可预测的算法会很昂贵。@CodesInChaos我认为引用的是BitLocker中使用的Microsoft的Elephant扩散器（download.microsoft.com/download/0/2/3/…—警告：下载PDF）。
欢迎使用密码学堆栈交换。您的问题之所以被迁移到这里，是因为与软件开发没有直接关系（Stack Overflow的主题），而在这里成为更多话题。请在这里也注册您的帐户，以便能够发表评论并接受答案。