I'm taking Prof. Boneh's crypto class from Coursera, and am unsure on the requirement for XTS mode for disk encryption.
It seems that CTR mode would do exactly what XTS can do, but is simpler to implement? In either mode, I will use the disk sector # to provide randomness to ensure that 2 sectors of same data will end up with different cipher texts. What subtlety have I missed?
Suppose you use the sector number times the number of AES blocks per sector as the initial value for CTR. If you successively store the content $M$ then $M'$ in the same sector $n$ then $E^{CTR}_n(M) \oplus E^{CTR}_n(M') = M \oplus M'$ (where $E^{CTR}_{n}$ is the encryption function with CTR mode and IV started for sector number $n$). CTR mode fails catastrophically when you reuse a counter value, because it's a pure xor stream cipher: xorring two ciphertext blocks that were produced with the same key and counter values cancels out the encryption. For example, if the block started out as all zeroes (which happens pretty often in practice) and an adversary manages to obtain both the initial ciphertext and the updated ciphertext, then the adversary has the confidential plaintext on a platter.
If you use the sector number as the initial counter, it's even worse since the second block of a sector shares a counter with the first block of the next sector and so on. That would enable an adversary to reconstruct a lot of content with even a single snapshot of the disk.
To use CTR safely, you need to generate a fresh counter value each time. You can use the sector number as part of the initial counter value, but there's little value in doing so, because you'll need to store the rest of the counter (some kind of per-block update count, a global counter value, a random value, or any other scheme) anyway.
XTS incorporates the sector number as a tweak. Any change in the plaintext results in a complete change of the content. An adversary who knows the content of a sector at two different times can observe whether the content of the sector has changed, which is unavoidable for deterministic encryption, but if the content has changed, then the adversary obtains no information about the plaintext.
If the only threat is that the disk is stolen, so that an adversary will only ever obtain one version of the ciphertext and no more plaintext will ever be encrypted after that, then I don't think there's any benefit in using XTS over CTR.
If the adversary can observe the ciphertext at different times, XTS does a better job. Not perfect though: you need the extra burden of storing an IV of some kind for that.
If the adversary can modify the ciphertext, then you need to worry about data integrity as well. CTR is extremely malleable: the attacker can flip plaintext bits by simply flipping the corresponding ciphertext bit. XTS is less malleable but still allows the attacker to replace good content with garbage or with older content. Authenticated encryption modes combine encryption with a MAC, and thus provide both confidentiality and authenticity (and if done right, integrity).
One answer would be nonce space: adding a tweak significantly increases the number of different nonce-tweak options you're allowed, thus increasing the maximum data that can be safely encrypted with a single key.
Update: In his modes paper, Rogaway quotes an earlier source the CTR was dismissed due to trivial malleability. This makes a lot of sense, since disc encryption isn't doing a great job if I can change whats on your disk without you knowing. An AE-based scheme (the topic of this) requires setting aside disk space for a tag.
