On 08/03/2014 10:45 AM, Andrew McGlashan wrote:
On 3/08/2014 10:48 PM, Bzzzz wrote:On Sun, 03 Aug 2014 18:20:19 +1000 I do not agree with that because using only zeros makes the result part predictable for the attacker:Yes, but the method of encryption used (aes-xts-plain64) does NOT lend itself to this kind of analysis. The cryptsetup FAQ documentation covers my use of /dev/zero .... we've had this discussion before ;-) https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup See step 6,
If I've already created an ext4 file system within the LUKS container and copied in data, would unmounting the file system and running zerofree against the /dev/mapper/* device be reasonable?
http://intgat.tigress.co.uk/rmy/uml/index.html
there is an earlier write of /dev/zero at step 3, but I think that is pointless unless you don't do the optional one at step 6.
As I understand it, step 6 will put encrypted zero blocks into disk blocks (e.g. apparently random data on the disk blocks) corresponding to the LUKS container, but will not touch disk blocks outside of the LUKS container. So, any disk blocks not otherwise written by the partitioner (parted) and/or LUKS (cryptsetup) will contain whatever they had previously. Step 3 is the overkill method for precluding disk blocks with leftover data, and has been my practice. If I know that I will be setting up a GPT partition table with one primary partition for LUKS that uses all available LBA's aligned to 1 MB boundaries, zeroing (/dev/urandom?) the first and last megabyte of disk blocks, partitioning, setting up LUKS in partition one, and zeroing the LUKS /dev/mapper/* device (step 6) should get all disk blocks, right?
Just don't use defaults;
Which parameters? What values instead? David