On 4/08/2014 5:43 AM, David Christensen wrote:
> 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?
If you do the /dev/zero against a volume, then no useful data will
remain on that volume ... you need to backup that file system first,
then restore it after you re-create the file system again.
> http://intgat.tigress.co.uk/rmy/uml/index.html
The zerofree option looks interesting and useful, wonder how well it
will work in practice.
> 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?
Yes, that is right according to my understanding.
>> Just don't use defaults;
>
> Which parameters? What values instead?
Here is an example of what I do when setting up LUKS volumes.
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -i 6000 \
-y --use-random luksFormat /dev/md3
An earlier message had more details and it was suggested that you don't
want xts ... after I sent it; but I'm not yet sure about that. It seems
that with FDE there is apparently a better option; but the author
considered FDE as a last ditch effort, preferring multiple encryption
choices on files or file systems (encfs like). After my brief reading,
I'm not yet convinced but I might be soon. I'll have to revisit that at
another time though. For now aes-xts-plain64 is good enough for me
(even if less good than another option which may or may not be available
with LUKS) ... at least until I can discover more with the luxury of
more time being available to do so.
I do disk mirroring first, then LUKS encryption on the mirror and the
LUKS volume [container], apply the /dev/zero process and eventually it
becomes an LVM2 volume group which then has LVM2 logical volumes as needed.
Cheers
A.
Attachment:
signature.asc
Description: OpenPGP digital signature