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?

  • $\begingroup$ I thought this already existed somewhere, but can't find a dupe. Either way, this is clearly stated so a good candidate to keep even if another exists. [ related ] $\endgroup$ Feb 21, 2014 at 15:10
  • 2
    $\begingroup$ just came cross this post sockpuppet.org/blog/2014/04/30/you-dont-want-xts, which does an excellent job of explaining this topic. $\endgroup$
    – shrek
    Feb 15, 2016 at 3:37

2 Answers 2


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).

  • $\begingroup$ Nice answer :-) $\endgroup$ Feb 21, 2014 at 15:40
  • 1
    $\begingroup$ Nice answer, but newer content replaced with older content will be a concern even if you use authenticated encryption. Prevention of replay attacks requires more than just authenticated encryption. $\endgroup$ Feb 21, 2014 at 15:54
  • $\begingroup$ @HenrickHellström Yes, it will be a concern for integrity, but not for confidentiality. I didn't dwell on the integrity part much. For replay protection, you can't have a deterministic scheme: there has to be something that distinguishes the latest, valid content from some older, formerly valid content. $\endgroup$ Feb 21, 2014 at 16:08
  • $\begingroup$ Perfect. Thank you so much. Gilles. I guess I missed couple of things here. First the reuse of the counter at different times and also the size of the block (e.g. 16 bytes) is smaller than the sector size 512 bytes. Prof. Boneh had mentioned possible leak of information when a sector revert back to a previous state, an observer can notice that change. $\endgroup$
    – shrek
    Feb 22, 2014 at 13:22
  • $\begingroup$ just came cross this post sockpuppet.org/blog/2014/04/30/you-dont-want-xts, which does an excellent job of explaining this topic. $\endgroup$
    – shrek
    Feb 15, 2016 at 3:34

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.

  • $\begingroup$ Update #2: I tried following up that reference (it goes to the appendix of IEEE Std 1619-2007) but the 'net here is shocking. Will try to fix later :) $\endgroup$ Feb 21, 2014 at 15:32
  • 1
    $\begingroup$ I think the most important reason not to use CTR is that it fails catastrophically due to counter reuse if the adversary can observe the ciphertext at different times. Against an active attacker, when you want integrity in addition to confidentiality, you need something else (typically MAC or AEAD) anyway. $\endgroup$ Feb 21, 2014 at 15:41
  • $\begingroup$ That's also a good one, but as you say it does rather depend on the attack model. I was simply quoting Rogaway quoting the IEEE. I'll try to provide the actual quotes later, but from what I can tell this place (as in, where I am, not Crypto.SE) is packet sniffing and killing all SSL calls, which is rather bothering me! $\endgroup$ Feb 21, 2014 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.