2

Why is it considered good practice to zero free space before formatting a luks drive? Do I need to do this even with a brand new usb flash drive that has never been used before?

Lost Crotchet
  • 125
  • 1
  • 7
  • 2
    You don't need or want to zero the partition. You want to fill it with random data, so that a hypothetical attacker cannot tell which sectors are used and which are not used. Usually this is done by opening it as a plain cryptsetup volume with a random key and dd-ing /dev/zero onto the volume. You then close the plain cryptsetup volume and run cryptsetup luksFormat. – AlexP Nov 07 '17 at 21:17
  • @AlexP Why don't you post this as an answer? – Zip Nov 08 '17 at 01:39

1 Answers1

5

You don't need or want to zero the partition. You want to fill it with random data, so that a hypothetical attacker cannot tell which sectors are used and which are not used. Usually this is done by opening it as a plain cryptsetup volume with a random key and dd-ing /dev/zero onto the volume. (This is very much faster than dd-ing /dev/urandom onto the partition.) You then close the plain cryptsetup volume and run cryptsetup luksFormat.

Let's say that the partition or file on which you want to create a LUKS container is $ENCRYPTED_CONTAINER and the name of the container is $CONTAINER; first, you fill $ENCRYPTED_CONTAINER with random data (the example code works on Ubuntu or other Linux variants where administrative commands are to be run with sudo):

sudo cryptsetup plainOpen --key-file /dev/urandom $ENCRYPTED_CONTAINER $CONTAINER
sudo dd if=/dev/zero of=/dev/mapper/$CONTAINER bs=1M
sudo cryptsetup plainClose $CONTAINER

Then you create a LUKS container and open it:

 sudo cryptsetup luksFormat $ENCRYPTED_CONTAINER
 sudo cryptsetup luskOpen $ENCRYPTED_CONTAINER $CONTAINER
AlexP
  • 10,217
  • 32
  • 41
  • ok thanks i understand now, but can the writing of the random bits wait until after the partition has been luks formatted? – Lost Crotchet Nov 08 '17 at 20:35
  • @LostCrotchet: You can do it after formatting it as a LUKS container, but it's more difficult to explain how to do it. Basically, all that `cryptsetup luksFormat` does is write a 2 MiB header where the LUKS master key and the 8 keyslots are stored; it doesn't touch the rest of the device. – AlexP Nov 08 '17 at 20:57
  • Can you not just simply call "sudo dd if=/dev/zero of=/dev/mapper/$CONTAINER bs=1M" on the luks partition whilst it is open? – Lost Crotchet Nov 08 '17 at 22:22
  • @LostCrotchet: Of course you can. But that's not random data, that's zeros encrypted with the same key as the useful data; so this would give the hypothetical attacker a long string of known plaintext, which could (theoretically) make their life easier. Filling up the partition takes a long time; why not do it the proper way and redo the `luksFormat` afterwards? After all, `cryptsetup luksFormat` takes very little time. – AlexP Nov 08 '17 at 22:32
  • 1
    ok then cant you just use "sudo dd if=/dev/random of=/dev/mapper/$CONTAINER bs=1M" instead? – Lost Crotchet Nov 12 '17 at 18:30
  • 1
    @LostCrotchet: Of course you can. It will be very very very slow (a few kilobytes per second, if that), and it will starve your server of entropy, but technically you can. You still did not explain why the usual method doesn't work for you. By the way, [there is *never* any good reason to use `/dev/random` instead of `/dev/urandom`](https://www.2uo.de/myths-about-urandom/). If you have a *very* good reason not to redo the luksFormat it is better to open a plain `cryptsetup` container *on the open LUKS container* with a random key and `dd if=/dev/zero` on it, the close it. – AlexP Nov 12 '17 at 18:33
  • what is the best approach for someone who has an operating system installed on the encrypted partition? will sfill be too slow as well? – Lost Crotchet Nov 12 '17 at 20:35
  • in regards to your previous comment, I have just created a luks flash drive (7.5Gb thumb drive), and then ran shred against the relevant /dev/mapper as a test, and it has already written gigabyte's worth of random bits in a few minutes... Isn't this somewhat synonymous to running `dd if=/dev/random of=/dev/mapper/$CONTAINER bs=1M` ? – Lost Crotchet Nov 12 '17 at 21:31
  • No, it probably isn't, depending on how you invoked `shred`(by default it uses a fast non-cryptographic PRNG); but it should be plenty good enough. Outside special applications ("special" as in classified secret or above) all this is not considered really necessary. In computer security it is important to have a "threat model", that is, to consider *who* your adversary might be. For non-national-security-classified applications, randomizing the encrypted container is likely overkill, because your adversary would not likely have access to nation-state levels of funding and power. – AlexP Nov 12 '17 at 22:03
  • ok thanks, i probably won't bother with any of this then :D – Lost Crotchet Nov 12 '17 at 22:39
  • Re filling the disk with known plaintext (all zeros) after a _cryptsetup open_ - that's easily solved by using a toss-away random key when you initialize the disk with zeros. Even if the attacker successfully breaks that encryption key all they'll gain is the ability to determine which sectors have been used since then. It won't help them decrypt those sectors since the keys are entirely different, and it won't help them learn which sectors are currently in use. – bgiles Nov 04 '19 at 21:51