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 '14 at 15:10
  • 1
    $\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$
    – user12136
    Feb 15 '16 at 3:37

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 '14 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 '14 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 '14 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$
    – user12136
    Feb 22 '14 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$
    – user12136
    Feb 15 '16 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 '14 at 15:32
  • $\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 '14 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 '14 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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