2015-08-23

First, please forgive me if I'm posting this question to the wrong community. Feel free to migrate this post to the right community if I was wrong.

I'm quite new to whole disk encryption (but not with encryption), especially with dm-crypt. I'm currently running Arch Linux and have read the documentation dedicated to that GNU/Linux distribution. Please correct me if I'm wrong in the assumption I make in the following summary: I want to start my knowledge on solid foundations. ;-)

There, wiki writters/maintainers advise us to prepare the disk first. i.e.: removing/erasing all previous content. This is necessary for 2 reasons:

(obviously) prevent the old data residing on the disk to be recovered;

more importantly, prevent the disk from disclosing usage pattern.

I understood the second point as it: since the encryption only encrypts new blocks of data we write, we need to securely erase previous data in a way to avoid displaying to a possible attacker the limits of the encrypted container. If we had written zeroes instead, an attackers could realize and think like this "hé, look! we see garbage here, and there, it's all filled with zeroes, I know where to keep my focus on try to decipher the data".

Also the same Arch Linux documentation explains the CBC (Cipher Block Chaining) encryption mode. According to what I understood, this method uses physical sectors and divides them by the size of the block size the algorithm uses.
For example, if we take AES which uses a 128 bits encryption size block and we have a physical sector of size 512 octets (Advanced Format aside), the computation to determine the number of blocks would be
512 * 8 bits = 4096 / 128 = 32 blocks.
Where one block of the sector is used for the IV (initialization vector).
If CBC is used with dmcrypt this means the same unencrypted content will appear encrypted differently on two different locations on the disk. In that way, when we prepare the disk for encryption, we can erase the disk content by first creating an encrypted container and filling it with zeroes. If CBC is used, the zeroes will appear differently on the disk on each locations. If CBC is not used, we indeed need to use urandom.

After some questions on IRC, it appears this is XTS which is used by default with dm-crypt. According to what I understood, XTS is just a variant of CBC allowing a physical sector size to be divided by the size of the block size of the algorithm used regardless of its size (e.g.: if a 512 sectors block was not divisible by the 128 bits of the AES algorithm, XTS would allow that).

EDIT: xts is not actually the default, this depends on how dmcrypt has been compiled in the GNu/Linux distribution. To see which algorithms and keys sizes are being used, simply type

Thus, before correcting the Arch Linux wiki, I want to make sure what is actually used behind dm-crypt: CBC or anther encryption method? Because it is recommended here to never use zeroes with dm-crypt, but that reason is wrong since non encrypted data appears encrypted differently on two different disk locations. If CBC or a variant is not used, I'll need to correct the assumption described on the wiki page "Securely wipe disk".

Also, Arno Wagner, the official dmcrypt FAQ maintainer, describes in the point 2.19, that using zeroes directly on the disk can take a very long time and that "Using cryptsetup and a plain dm-crypt device with a random key, it is much faster and gives you the same level of security."

He then adds the following command to type: cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped, but he is still using urandom and not zeroes. I cannot understand why he is not using zeroes instead and why using urandom in a container would be much faster than outside the container, directly on the disk.

EDIT: Ok, Argo added a precision in his FAQ. -d /dev/urandom is just used as a random password for the encryption.

Also, since I need to install encryption on 3 differents machines using 3 kinds of devices: a brand new SSD, an already used SSD, and a standard HDD. Since SSDs use flash, I don't know how to prepare the disk. The question is still present with the new SSD, do I need to wipe it with random values first? What about TRIM, is Linux smart enough to figure out he doesn't have to use TRIM since this is weakening the encryption?

Help is greatly appreciated.

Show more