2

The old cryptsetup default is aes-cbc-essiv:sha256. The new one is aes-xts-plain64:sha256. I don't know that much about cryptography but I assume the standard was changed for a reason. Also there can be found information like:

[...] if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher --cipher aes-cbc-essiv, more information leakage may occur from trimmed sector observation than with the current default.

So should I upgrade my old encrypted volumes?

1

There is no security advantage to AES-XTS over AES-CBC-ESSIV—in fact, in the standard threat model for disk encryption (an adversary can read multiple snapshots of a disk, e.g. because of bad sectors on spinning rust or wear-leveling in an SSD), XTS leaks slightly more information than CBC-ESSIV: XTS leaks exactly which blocks in each disk sector didn't change, whereas CBC-ESSIV leaks only which leading blocks of each disk sector didn't change. Here a ‘block’ is the block size of the underlying block cipher—16 bytes, for AES—and ‘disk sector’ is the smallest unit of I/O on the underlying storage medium—typically 512 bytes or 4096 bytes.

For example, suppose you write disk sector 8137 twice, first with the text foo bar baz qux zot, and then with the text foo barbaxqux zot. If we pretend a cipher block is a single word, then:

  • Under XTS, the two versions of disk sector 8137 will look like:

    1. dbk iww dfv ngv jus
    2. dbk iwwoywngv jus
  • Under CBC-ESSIV, the two versions of disk sector 8137 will look like:

    1. dbk iww dfv ngv jus
    2. dbk iwwoyw bst kib

That is, changing a single cipher block in the plaintext under XTS changes only the corresponding block in the ciphertext, whereas under CBC-ESSIV it also changes all subsequent blocks. So the XTS adversary can tell exactly which blocks you changed, but in CBC-ESSIV the adversary can only tell how far along in the disk sector the changes started—they can't tell whether you changed one block, or two blocks, or all of the final blocks.

The only reason to prefer AES-XTS is that there's a United States federal government standard for it, unlike AES-CBC-ESSIV, and nobody in the Western world was ever fired for choosing a United States federal government standard for cryptography.


I am not sure what the text you quoted is on about, but here are my two best guesses:

  1. For some reason, dm-crypt foolishly passes TRIM commands through for disks configured to use aes-cbc-essiv, but not for disks configured to use aes-xts-plain64.
  2. A message got garbled along the way, and the author of the Arch Linux wiki page thought that aes-cbc-essiv is subject to the standard watermarking attack on aes-cbc-plain…which was the motivation for aes-cbc-essiv in the first place.
| improve this answer | |
  • Isn't CBC-ESSIV more malleable than XTS? Obviously, it'd be better to use GCM or at least a wide-block mode like EME rather than hoping that 16-byte granularity malleability doesn't give an attacker anything useful, but that doesn't mean that CBC-ESSIV is always more secure than XTS. – forest Dec 13 '19 at 2:32
  • 1
    They're both malleable. Malleability is not relevant here because the standard threat model that disk encryption can defend against—which is very weak!—does not include malicious changes to your disk. If the border police take your laptop away from you and then return it later, disk encryption whether with CBC or XTS will not save you—you need a new laptop. If you want to do iSCSI over the internet on a potentially malicious storage server, disk encryption will not detect when the server rolls back blocks of data—you need more than mere disk encryption. – Squeamish Ossifrage Dec 15 '19 at 20:58
0

That depends, if you have a lot of very sensitive information in a large volume and you need to be as secure as possible then the answer is yes. Otherwise I'd say it is up to you, but I would not lose any sleep over it.

| improve this answer | |
0

It depends on your threat model. CBC is more malleable, but XTS leaks more information.

CBC-ESSIV (and plain CBC, which is additionally vulnerable to the watermarking attacks that ESSIV prevents) is vulnerable to malleability attacks where an attacker can change the ciphertext in a way that modifies resulting plaintext predictably, even if they don't have access to the key. XTS is not nearly as vulnerable, although it is still partially malleable, allowing an attacker to randomize plaintext with 16 byte granularity. Neither XTS nor CBC-ESSIV provide true integrity like an authenticated mode can.

XTS mode is not without its problems, though. In terms of information leakage, XTS is actually worse than any CBC mode. If an attacker can view the ciphertext on your disk in between changes, they can detect which individual blocks changed and which did not change. CBC modes do not leak as much information, since a single changed 16 byte block also changes all subsequent blocks in that 512 or 4096 byte sector. This is explained very well in Squeamish Ossifrage's answer (though I disagree that there is no advantage to XTS and no reason to use it; some threat models may call for it over CBC).

Overall, if your adversary might modify the encrypted contents of your disk and give it back to you without your knowledge, then XTS is more secure than CBC-ESSIV. If, on the other hand, your adversary may be able to see changes to the encrypted volume over time, then XTS is less secure.


The Linux kernel does not support it at the time of this answer, but there is another mode called EME2 which is a wide-block mode. It requires two passes over the plaintext so it is half as performant as most other modes, but it leaks very little information and is not nearly as malleable. Wide-block modes act on the entire sector, so changing a single bit in the entire sector will randomize the entire sector.

| improve this answer | |
  • I do not endorse this advice because if your threat model includes malicious modification to the disk, then disk encryption cannot meaningfully protect you, whether you use CBC or XTS. I think it is distracting to draw attention to such minor differences—adversary can flip a bit and randomize next block, vs. adversary can randomize a chosen block—when you really need authentication, which disk encryption cannot provide. This attention on ‘malleability attacks’ has misled many people into false senses of security about XTS that are not justified by cryptography. – Squeamish Ossifrage Dec 15 '19 at 21:04

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.