# What role does the mode of operation play in Veracrypt vs. Bitlocker?

There is this VC vs Bitlocker debate . It is always about open source and not open source , alternative algorythms , portability , etc.... That is nothing new , but once I saw someone useing the mode of operation as an argument . VC uses XTS while BitLocker uses CBC . I am not a professional and my experience with modes of operations is very limited . I know that XTS is used for Drives and partitions and CBC is like a default mode for block ciphers . But does it really count ? Every mode of operation is secure in some way , right ? And if CBC really is not as secure as XTS , then why does one of the bigges software companies in the world ( Microsoft ) use it in there encryption solution ?

The final part of your question ignores that there are multiple reasons to choose an encryption mode, other than bits of security. Different encryption modes offer different levels of performance, and there is more trust in modes that have been around longer.

The model of an attacker used for disk encryption is slightly different than the model used for other attacks.

To quote wikipedia:

Disk encryption methods aim to provide three distinct properties:

The data on the disk should remain confidential. Data retrieval and storage should both be fast operations, no matter where on the disk the data is stored. The encryption method should not waste disk space (i.e., the amount of storage used for encrypted data should not be significantly larger than the size of plaintext).

The first property requires defining an adversary from whom the data is being kept confidential. The strongest adversaries studied in the field of disk encryption have these abilities:

they can read the raw contents of the disk at any time; they can request the disk to encrypt and store arbitrary files of their choosing; and they can modify unused sectors on the disk and then request their decryption.

A method provides good confidentiality if the only information such an adversary can determine over time is whether the data in a sector has or has not changed since the last time they looked.

Plain CBC mode is susceptible to a watermark attack in these cases. When it comes to disk encryption however, normally CBC mode + ESSIV is used which takes care of the watermarking attack. CBC also suffers from the possibility of a malleability attack. (Basically another word for the commonly known CBC bit flipping attacking)

XTS mode offers protection against watermarking built in, but the chief reason to choose XTS is due to its support for ciphertext stealing. Basically ciphertext stealing is a property which allows data sectors whose length is not evenly divisible by the block size to be securely encrypted without expanding the ciphertext.

XTS however has two disadvantages. The size of the key is doubled for the same strength of encryption, and it does not provide protection against data tampering. (Modifying the ciphertext will result in valid decryption to gibberish plaintext) Redundancy for sectors is handled at an application level, and it is needed in both modes. Both veracrypt and bitlocker support XTS mode.

The standard application for disk encryption is to store a sequence of fixed-width, say 512-byte or 4096-byte, disk sectors with random access. The standard threat model for disk encryption is a limited adversary that can only see multiple snapshots of a disk. The only security property that disk encryption provides is that the adversary can't learn more than which parts of the disk content did not change. (Forgery is outside the scope of this application: if an adversary can modify your laptop's disk, you have bigger problems and should throw it away and restore from backups in a new clean laptop.)

In this scenario, XTS leaks at least as much information as CBC—though not much more—by revealing a slightly finer-grained picture of which cipher blocks did not change. Details:

1. What is CBC? In typical CBC mode for disk encryption, disk sectors must be evenly divided into units of cipher blocks. For the $i^{\text{th}}$ disk sector, the $j^{\text{th}}$ ciphertext block is $C_{i,j} = E_{k_0}(P_{i,j} \oplus C_{i,j-1})$, where $P_{i,j}$ is the plaintext block, and $C_{i,-1} = H_{k_1}(i)$ is some pseudorandom function of the disk sector number—e.g., $C_{i,-1} = E_{k_1}(i)$, where $k_1 = \operatorname{SHA256}(k_0)$ in Linux dm-crypt ESSIV, or $k_1 = k_0$ in NetBSD cgd. (Failure of the disk encryption scheme to choose an unpredictable $C_{i,-1}$ for each $i$ is a violation of the CBC security contract. In practice, this leads to watermarking attacks.)

What leaks from CBC? Flipping a bit in plaintext block $j$ of disk sector $i$ from one snapshot to another affects ciphertext block $j$, and transitively affects ciphertext block $j + 1$ because $C_{i,j + 1} = E_{k_0}(P_{i,j + 1} \oplus C_{i,j})$, and so on to the end of the sector. Thus what an attacker learns from two snapshots is which prefixes of each disk sector, in units of cipher blocks, did not change.

(BitLocker also used to apply a fixed permutation called the Elephant diffuser to each disk sector, so that you don't even get to learn which prefixes did not change: changing any bit in the plaintext of a disk sector affects every other bit in the ciphertext of a disk sector. But Microsoft removed the Elephant diffuser from BitLocker at some point, so presumably now it is like other CBC modes for disk encryption.)

2. What is XTS? In XTS mode, disk sectors need not be evenly divided into units of cipher blocks. For example, AES-XTS, with 16-byte cipher blocks, is defined on 520-byte disk sectors, which typical CBC mode for disk encryption is not. But the vast majority of all disks you will ever encounter have 512-byte or 4096-byte sectors, so this is not likely to matter to you, and we'll assume disk sectors evenly divide into cipher blocks. For the $i^{\text{th}}$ disk sector, the $j^{\text{th}}$ ciphertext block is $C_{i,j} = E_{k_0}(P_{i,j} \oplus T_{i,j}) \oplus T_{i,j}$, where $P_{i,j}$ is the plaintext block, and the tweak $T_{i,j}$ is a pseudorandom function of $i$ that is different for each $j$. (The gory detail of the tweak $T_{i,j}$ is not important here.)

What leaks from XTS? Each cipher block is encrypted independently, so flipping a bit in one cipher block doesn't affect any other cipher blocks. Hence an adversary learns from two snapshots exactly which cipher blocks changed or did not.

(The gory detail of the tweak is that $T_{i,j} = E_{k_1}(i) \otimes x^j$, where $E_{k_1}(i)$ is interpreted as a polynomial in $\mathbb{Z}/2\mathbb{Z}$ (e.g., $10110 \longleftrightarrow 1 x^4 + 0 x^3 + 1 x^2 + 1 x^1 + 0 x^0 = x^4 + x^2 + x$), and $\otimes$ is polynomial multiplication modulo a standard irreducible degree-$n$ polynomial $f$ for cipher block size $n$, typically $x^{128} + x^7 + x^2 + x + 1$; that is, $\otimes$ is multiplication in $\operatorname{GF}(2^n)$ represented by $(\mathbb{Z}/2\mathbb{Z})[x]/(f)$.)