You Don't Want XTS (opens in new tab)

The block layer is a poor location to support security, whether access control or encryption. The lack of knowledge of upper layers & the resource constraints of the lower layers (block stealing for metadata) unnecessarily hamper its security and performance.

The only reason for block-level encryption in software is because it was too much work to retrofit UFS, ext23456fs, FAT, NTFS, etc. with encryption. The block device provided a convenient bottleneck, and no one cared too much about the downsides you bring up because it seemed better than nothing.

ZFS generally gets this right, using AES-CCM (an AEAD mode as you recommend). It also has proper integration with the deduplication layer so encryption doesn't waste space. These reasons and more show why security needs to be implemented at the filesystem layer.

Another good example people here may be familiar with is Tarsnap. Again, it handles encryption, integrity protection, and deduplication without storing keys on the server side or unnecessarily restricting itself to a block device metaphor.

You're right that TC+DB are not a safe combo. Dropbox needs to be the encrypted Dropbox.

What kind of access are you assuming the attacker has here? Modifying the ciphertext stored with Dropbox?

Evil Maid attacks that I've heard described before typically involved modifying (unencrypted and unauthenticated) bootloaders or kernels, rather than FDE ciphertext, although I realize that's not part of the definition of the attack.

Here's one possible approach.

Assume the attacker can modify plaintext on disk indirectly. This might be viable if e.g. the user's browser cache lives in the TC volume. (Not sure what typical TC-in-Dropbox usage patterns are, so this may or may not be realistic.)

Further assume that the attacker can observe ciphertext changes in Dropbox.

XTS is vulnerable to the same byte-at-a-time plaintext recovery attacks as ECB. This is usually irrelevant, because adaptive chosen plaintext attacks are outside the threat model considered for FDE. But in our scenario, the attacker has at least some degree of plaintext control.

The success of this attack will depend a lot on how fine-grained the attacker's control over his insertion point is, i.e. can he reliably write to the same location over and over again? Any number of components might thwart that control, so I'm not sure how easy it will be to make this work.

I guess the question is if you could do bad things to truecrypt itself this way, or if it would be easier to rely on user intervention. There is also "what can be done by Dropbox itself" (potentially via court order) vs what could be done by mitm (not sure what protections Dropbox has against this; if it uses the host ca certs to authenticate vs in app cert pinning (which is obvious and good), etc.

Being able to "glitch" someone's truecrypt volumes without even compromising the crypto could lead to fun. Also, OS/file system cruft on the level above, essentially the equivalent of an .htaccess file, could be fun.

After reading the original article and this whole thread, including some quite useful discussions about the security goals of disk encryption, I'm convinced that this is extremely hard (with XTS) under realistic attack scenarios.

However, I've been reminded that a realistic attacker can do much more to an FDE volume than we would first imagine. So, I'm planning to try to play around with this to improve my intuition of how bad the attacks actually are. Thanks for the challenge.

... huh. Actually, suppose the attacker could somehow cause a very large number of file downloads to happen (with known sequence, timing, and contents). The Birthday Paradox gives the attacker a high probability of being able to see a pair of files from two separate sets of files (of different kinds and different origins) land on a particular sector at different times. When that happens, the attacker can then substitute one for the other.

If we think of a computer for some reason downloading and storing a lot of "trusted" files and a lot of "untrusted" files, and that the attacker can see empirically where each file was stored, then when a trusted file gets stored at an offset where an untrusted file was previously stored, the attacker will be able to substitute the contents of the latter for the contents of the former. For this attack to be harmful, the untrusted file that was stored at that location just needs to contain something that it would be harmful for the attacker to be able to replace the corresponding trusted file with.

>It's apparently pretty common for people to create virtual Truecrypt volumes and stick them on Dropbox, as a sort of poor-hacker's encrypted Dropbox.

People do that? encfs/ecryptfs sounds like a much better fit for that use case. Encryption is per file and you can even disable the filename encryption if you want to still be able to navigate your files using their interface. Are there no good similar solutions for Windows/OSX?

Would you mind expounding? It sounds very interesting, but I'm having trouble figuring out how an evil maid attack might be employed against Dropbox-based Truecrypt volumes, since people can't boot from those.

The post ends with the takeaways I'm hoping for:

1. Try not to rely on FDE at all.

2. For God's sake don't use XTS for anything other than FDE.

There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post.

Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that.

You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).

I agree. Although the article content is good and reaches a good, nuanced conclusion, the title is going to confuse people. Many people will only ever encounter XTS when setting up full disk encryption with dm-crypt, where they'll be presented with the choice between XTS and CBC-ESSIV. This is already a confusing choice with no good context to help a user make a decision. Remembering this headline, I bet some people are going to pick CBC-ESSIV over XTS, which is wrong.

The title is also somewhat link-baity, since I clicked expecting bombshell revelations about XTS. I suggest the mods to change it to "You don't want XTS (except for full disk encryption)."

What? No. Don't do that.

This is a good question. Here are some reasons:

* If you're working with 512 byte sectors, the cost of individual MAC tags gets high.

* No matter what your sector size, reserving space for the MAC tag gets you odd-sized sectors.

* Most importantly, what does it mean to have a sector with a bad MAC? How does that get reported back to the filesystem? Filesystems aren't designed to cooperate with the disk to track cryptographic attacks.

By the time you solve that last problem, you've already gotten yourself pretty far down the track of just providing crypto in the filesystem layer. Which, because the filesystem layer is format-aware, you might as well just keep going and make a proper cryptographic filesystem.

Couple responses:

You scare-quote "unclear security goals", but that's not my objection, that's Phil Rogaway's objection. And his argument (and Ferguson's argument, and Liskov's argument) isn't hard to understand: by adopting disk sectors as the setting for your encryption, you trade transparency (the ability to use encryption on any filesystem) for a whole mess of constraints, which the article you're commenting on lays out in detail. The worst of these constraints is that you lose any real authentication, but the fact that XTS is basically XEX-ECB is another problem.

You've also taken the "two keys" issue out of context. The issue isn't that it unnecessarily uses two keys. The issue is that it's hard to derive clean security proofs for XTS, because of all its complications. The way Rogaway puts it: there are three constructions involved in XTS --- the XTS wide-to-narrow block adapter, the "XEX2" two-key XEX construction for full narrow blocks, and the "XEX3" two-key construction for partial narrow blocks.

I believe you're also wrong about the Evil Maid scenario. Perhaps you're getting hung up on a detail that I wasn't implicating (for instance, booting from the drive). The issue is that in a normal FDE setting, attackers don't get repeated use-tamper-use cycles. But in a cloud-backed FDE setting, they easily do get that, so more sophisticated versions of the same attack scenario are possible. Think "Evil Maid" here in the same sense as Kenny Patterson used the "BEAST" attack scenario to build a plausible attack on RC4.

The problem with XTS is that there are better modes you can use, even for sector-level encryption, if you shake off the constraint that you're working with physical disk geometry. Which, in the real world, a lot of FDE users can in fact do, because they're not working with real disks but rather virtual disks stored on cloud filesystems.

If you don't need to comply with physical disk geometry, it is probably feasible to get block-level encryption with strong authentication guarantees, and with a native wide-block PRP that will get rid of the ECB data leak in XTS.

Finally, don't use XTS for anything but FDE, even if you know what you're doing. That's a bit of a tautological statement for me to make, because if you know XTS, you also know that it's only meant for FDE --- but I've been getting comments from people who have seen XTS used in application-layer crypto. Bad. Ick.

The AES-NI properties that XTS exploit can also be exploited by better wide-block-narrow-block constructions; Rogaway for instance suggests that XTS could have cleaned up the CTS construction by using a better understood Feistel construction.

Even better would be a "native" wide-block tweakable cipher, one that created a strong PRP out of the entire sector, rather than chunking the sector into narrow blocks and then ECB'ing those narrow blocks. However you did that, it would also probably involve invocations of the AES block transform, and thus benefit from AES-NI.

But you're right: XTS has a convenience advantage for encryption in the standard hardware block device setting. What's sad about that is that simulated hardware block encryption is actually not a particularly strong protection for users.

As I mentioned above, ZFS is a good example of filesystem encryption without the block device constraints.

But between your OS and the hard drive in your laptop, use whatever full disk encryption software that is best supported & most secure. He's not criticizing FDE in general, he's saying "don't constrain yourself to the block device model if you're designing database encryption etc etc."