What is the advantage of XTS over CBC mode (with diffuser)? I have some problems in understanding the "advantage" of AES-XTS compared to CBC with diffuser.

I read something about FileVault, in this paper they mention the two modes of operations XTS and CBC (with diffuser) and the advantages of XTS.

Both modes encrypt data units almost the same way. For CBC, the sector number is somehow used to build the IV, for XTS, there is a "tweak value", which also includes (somehow) the block offset, so each data block can be encrypted independently (makes sense when encrypting harddrives/partitions). I cannot really see the advantage of XTS.

Now, they write the following about XTS:


  There are several advantages over alternatives such as AES in CBC: there is no requirement for an initialization vector (the tweak key can be derived from the block number); each block is encrypted differently (since the tweak value will be different); and unlike AES-CBC, AES-XTS prevents an attacker from changing one specific bit in a data unit by xor-ing each AES input with a different shifted version of the encrypted tweak.


Maybe they just compare XTS against CBC (without diffuser)... if so, does anybody know any advantage of XTS?

And can somebody explain the second advantage: "AES-XTS prevents an attacker from changing one specific bit in a data unit by xor-ing each AES input with a different shifted version of the encrypted tweak."?
XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data.

However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ciphertext. Let's say that an attacker happens to know some message says 


  "blah blah Give Alice \$400 ... blah blah blah".


If this message is encrypted using CBC, the attacker can tamper with the ciphertext in such a way that it will now decrypt to


  "blah blah !^%@^^ Give Alice \$800 blah blah blah"


The \$400 has become \$800. This is what your quote about "AES-XTS prevents an attacker from changing one specific bit in a data unit" refers to. Here I write !^%@^^ to indicate that the previous 16-byte block will become gibberish once decrypted, and this gibberish will be beyond the attacker's control.

On the other hand, using XTS prevents this attack. The attacker can corrupt a message by turning any 16-byte block into random gibberish, but he will not be able to have the same degree of control as he did in the CBC example.

But Microsoft decided not to use XTS anyway. The reason is that the ability to corrupt a 16-byte block could still be damaging. Here's the quote from the paper dchest linked:


  For example, there could be
  a configuration file (or registry entry) with a value that, when set to 0, creates a security
  hole in the OS. On-disk the setting looks something like "enableSomeSecuritySetting =
  1". If the start of the value falls on a 16-byte boundary and the attacker randomizes the
  plaintext value, there is a $2^{16}$ chance that the first two bytes of the plaintext will be 0x30
  0x00 which is a string that encodes the ASCII value ’0’.


(This quote is referring to the LRW tweakable cipher, but the XEX tweakable cipher used in XTS has the same problem).

Adding a diffuser. Using a diffuser is Microsft's solution to this problem. The idea here is to "mix" the plaintext up before encrypting it so that an attacker can't change \$400 to \$800 --- meddling with part of the ciphertext will change almost the entire plaintext, not just small parts of it.

This sounds good, but there's a catch: No one actually knows if Microsoft's diffuser actually is secure. To my knowledge, it hasn't received any published formal analysis from cryptographers. This means you should be skeptical about relying on it. Microsoft acknowledges this:


  On the disadvantage side, the diffuser is a new unproven algorithm, and this inevitably
  leads to questions. Without extensive public scrutiny and analysis of an algorithm, there
  is a justified skepticism about its security. People are reluctant to trust new algorithms.
  So why did we choose this option anyway? In our final analysis, we decided this was the
  better choice for our product. The performance gain over the alternatives was important
  enough to outweigh the disadvantages of a new diffuser algorithm. Time will tell whether
  we made the right choice.


The bottom line.
XTS is less malleable than undiffused CBC. However, CBC+Diffuser is probably less malleable than XTS, at least for practical purposes.

An important aside.
Neither CBC nor XTS were designed to be non-malleable. Ensuring that ciphertexts are not tampered with is a separate problem, one that should be solved by using Message Authentication Codes (MACs), such as HMAC-SHA256. The reasons MACs aren't typically used for full-disk encryption algorithms are (1) performance issues and (2) using a MAC requires storing extra information with the ciphertext, which makes adding it transparently a bit tricky.

A middle ground between MACs and diffusers would be to use a wide-block encryption mode, such as CMC, EME, or HEH. You can think of these as having a "built-in" diffuser, that makes them non-malleable. Unlike Microsoft's diffuser, these algorithms have formal security definitions and peer-reviewed mathematical proofs. They are secure under the assumption that AES is secure. Microsoft opted not to use these because of (1) performance issues and (2) patents.