In a blog post I recently read called "You Don't Want XTS," the author explains some of the pitfalls of using XTS to encrypt filesystems. Specifically, he recommends against ever sharing encrypted file-based filesystems over services like Dropbox when the file-based disk is encrypted in XTS.

Since TrueCrypt offers a fairly easy way to create encrypted file-based filesystems, I've used it in the past for keeping things safe when I need to transport around a filesystem on a thumb drive or over the internet.

Seeing as dm-crypt uses AES-CBC with an ESSIV by default instead of XTS, does it fall victim to the same vulnerabilities as TrueCrypt does in XTS?

1 Answer 1


The criticisms about XTS make sense in a context when attackers can observe successive versions of the encrypted disk (i.e. the attacker steals your laptop, makes an image of the whole disk, then puts the laptop back in your bag, and you did not notice anything; and he does it again tomorrow, and the day after tomorrow, and so on...). With XTS, every 16-byte block gets encrypted by itself, so the attacker may notice when two successive versions of the same encrypted block (the same 16-byte block within the same sector of the harddisk) contain the same data. This potentially allows for traffic analysis. If the attacker goes active, then he can put back an old version of any block, and can do so for all blocks independently.

With CBC+ESSIV, each sector has its own IV, so our recurring attacker can notice when a new version of a sector begins with the same sequence of blocks as a previous version. CBC is such that if two plaintext blocks differ at some point in a sector, the remaining blocks in that sector will diverge. In that sense, compared to XTS, the attacker's abilities for traffic analysis of CBC+ESSIV are reduced. For instance, if two versions of a given sector use the same plaintext value for the 13th block, this will be apparent with XTS, not so with CBC (unless the versions for the 12 previous sectors are also unchanged).

On the other hand, an active attacker is often happier with CBC, because he can alter bits at will within a block (provided that he does not mind replacing the previous block with uncontrollable random junk).

So no, dm-crypt does not have the exact same vulnerabilities as TrueCrypt. The envisioned scenarios (repeated eavesdropping of the same disk, hostile alterations...) are not the primary goal of full-disk encryption; really, FDE was meant for the "stolen laptop" situation, in which you don't get it back, ever. Neither solution behaves well against a more industrious attacker, but they don't fail in exactly the same ways.

  • Thanks for the awesome answer; but TL;DR if I want to store an encrypted filesystem in a single file and put that on Dropbox, what should I use? Commented Jul 28, 2014 at 18:26
  • 2
    If you put the encrypted filesystem only once, then there is no problem. Just do it. Potential vulnerabilities begin to occur if you then retrieve the filesystem, modify it, then put it back on Dropbox: the successive versions become visible to attackers. What you can do is to take a filesystem image (not necessarily encrypted with anything), then encrypt it with GnuPG before upload, and decrypting it when downloading it. This will be stronger, both against passive and active attackers.
    – Tom Leek
    Commented Jul 28, 2014 at 18:39
  • Wish that there was a way to do this so that filesystem writes would automagically be encrypted to disk inside of a GPG file. Commented Jul 28, 2014 at 19:02
  • 1
    GnuPG's better encryption comes from the fact that it processes the whole file in one go, with a fresh random IV. All the difficulty of FDE is that it tries to support efficient updates, where only the data chunks that are updated get reencrypted. In the file-on-Dropbox case, the encryption should really occur when uploading the filesystem image, not for each file write.
    – Tom Leek
    Commented Jul 28, 2014 at 19:11
  • I'm trying to think if there's a way I could decrypt the filesystem directly into memory (it's not going to be too big) and then once finished encrypt it directly through PGP... Commented Jul 28, 2014 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .