2
$\begingroup$

Can cryptsetup suggestion of wiping a disk before encryption with zeros written to an encryted device as described in question 2.19 as the recommended method on the CryptsetupFAQ (the part that starts with "For device set-up, do the following:" (which ends writing the encrypted random looking represantation of zeros) be a weak point as an attacker, knowing that the device is encrypted with LUKS, could suppose that the end of the disk is just zeros. With this information could he more easily find the key used on the initial wipping and, with this info, isolate the part of the disk that actually has relevant encrypted information?

$\endgroup$
  • $\begingroup$ It doesn't suggest to wipe as 0. The conventional recommendation if you want to not just do a zero-wipe is to use something like $\endgroup$ – kelalaka Dec 9 '18 at 22:48
  • $\begingroup$ I still don't see the encryption of zero. It takes input from /dev/urandom $\endgroup$ – kelalaka Dec 9 '18 at 22:59
  • $\begingroup$ At the first paragraph of 2.19, they say "the conventional recommendation" is to use /dev/urandom but on the third paragraph they say "For device set-up, do the following:" cat /dev/zero > /dev/mapper/to_be_wiped $\endgroup$ – Rsevero Dec 9 '18 at 23:03
  • 1
    $\begingroup$ @Rsevero The fundamental issue you bring up is that what you believe to be zero is not zero on the media. If you have an encrypted volume, it has a master key that will be used to encrypt the stream onto the media. Therefore, cat /dev/zero > /dev/mapper/to_be_wiped is actually not placing a bitstream of zero onto the media. Depending on the block mode, and other settings, you could get enough information for tell where the volume started, stopped, and possibly the key. I think that the documentation is also fragmented. $\endgroup$ – b degnan Dec 10 '18 at 1:33
  • $\begingroup$ @bdegnan There is no block mode where that would give away the key. $\endgroup$ – forest Dec 10 '18 at 9:15
2
$\begingroup$

The output of an encrypted stream of zeros is absolutely indistinguishable from random data.

What you do is not write zeros to the block device for the drive, but for the encrypted mapping. That is, instead of writing zeros to /dev/sdx, you write to /dev/mapper/sdx_crypt. This results in the contents on the actual drive being completely randomized. Even though an attacker may know that zeros were encrypted, they would be no closer to finding the key than before. If they were, it would mean the underlying cipher is vulnerable to a known plaintext attack, and none of the supported LUKS ciphers (AES, Twofish, Serpent, etc.) are. In fact, any symmetric cipher that was badly vulnerable to a known plaintext attack would be considered fatally broken, and would be either revised or discarded.

To prove a point, you can see that many high-quality cryptographic random number generators work by encrypting a counter with a block cipher. An attacker knows exactly what was encrypted by the block cipher. They know that the nth block of output is an encryption of integer n itself, yet it doesn't make it possible for them to predict any of the output or retrieve the key. Ciphers are stronger than you think.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ I was wondering about a "known plaintext attack (it's great to know the proper name of things ;) . Thanks for the clear answer. $\endgroup$ – Rsevero Dec 10 '18 at 9:36

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.