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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53de90f5.2080...@holgerdanske.com
