luks dm-crypt + dd if=/dev/urandom. post-install

Molly · 04-16-2008, 05:02 PM

Code:

line:~# uname -a 
Linux line 2.6.22-3-amd64 #1 SMP Tue Feb 12 09:22:35 UTC 2008 x86_64 GNU/Linux
line:~# cat /etc/debian_version 
lenny/sid

The way I understand this so far, most people seem to recommend the volume to be encrypted should be filled with urandom (dd if=/dev/urandom of=/dev/sdX) prior to the luksFormat in order to reduce the chances of an attacker being able to determine what portion of the drive is actually encrypted data. Is this also the method used by the Debian installer to initialize/erase the luks drive?

I'm a bit amateur when it comes to drive encryption- Would the benefit of dd'ing urandom to a new hd prior to creating a luks/dm-crypt volume diminish as the actual amount of data written to the filesystem increased?
ie Would there be no practical point/benefit in spending the time to urandomize the drive if it were actually a new hd and also filled to capacity with encrypted data?

By my estimate it would take 40 hours to fully dd urandom to this partition which is the only partition on the drive and is using the full 750gb drive capacity. The actual data on the partition will using near the full capacity. I'd like to know if this 40 hours of continuous dd would be a waste of time/resources in the end.

One other way I've seen mentioned is to run 'badblocks -t random ...'. What I was thinking of doing was simply to combine badblocks + mke2fs via 'mke2fs -c ...' after I had already created/mapped the crypt volume.

any suggestions or input are very welcome.

thanks

Molly · 04-16-2008, 06:37 PM

I want to know if there is any way to invoke badblocks with the -t random option if called from mke2fs.

Here's my mke2fs line:

Code:

 mke2fs -m 0 -c -c -v -L mirror -T largefile -j /dev/mapper/mirror

The extra '-c' calls badblocks in read/write mode. Id like this to use random data as this will be an encrypted volume.

man page for badblocks strongly discourages running badblocks outside of invocation through mke2fs. Is it possible to pass any additional options to badblocks through mke2fs such as a direct command like:

Code:

 badblocks -c 10240 -w -t random -s -v ...

thanks

unSpawn · 04-16-2008, 07:16 PM

Quote:

Originally Posted by Molly

Is this also the method used by the Debian installer to initialize/erase the luks drive?

I don't know but if it uses scripts you can find out by grepping those for it.

Quote:

Originally Posted by Molly

Would the benefit of dd'ing urandom to a new hd prior to creating a luks/dm-crypt volume diminish as the actual amount of data written to the filesystem increased? ie Would there be no practical point/benefit in spending the time to urandomize the drive if it were actually a new hd and also filled to capacity with encrypted data?

Sure. AFAIK disks leave the factory with a single written pattern, so if you don't break that pattern by overwriting with randomised data or fill the drive to the max with encrypted content right away then if seized it is easier to spot areas where data resides. That doesn't say anything about actually being able to *break* the encryption though depending on situation and location ze judicial system may hav ozzer vays to meek you talk anyvay.

Quote:

Originally Posted by Molly

By my estimate it would take 40 hours to fully dd urandom to this partition which is the only partition on the drive and is using the full 750gb drive capacity.

Could be done faster, see this, start at the "entropy.txt" line. Provided you have your current kernels source installed compiling, installing and using frandom takes about a minute.

Molly · 04-17-2008, 07:57 PM

Thanks for the tip, I'm looking into this.

One other question. If i create the luks volume and open the mapper device, then invoke badblocks from mke2fs for the entire partition, would this then have the same effect as randomizing the entire drive simply because i am doing a read/write test of an luks volume?

Code:

mke2fs -m 0 -c -c -v -L molly -T largefile -j /dev/mapper/mirror

unSpawn · 04-18-2008, 07:51 AM

You've asked that in a separate thread, not waiting to find out how this thread would wind up, so asking here counts as a duplicate post. Please don't.

Molly · 04-18-2008, 09:24 PM

Lets look at what I posted in the other thread:

Quote:

I want to know if there is any way to invoke badblocks with the -t random option if called from mke2fs.

Here's my mke2fs line:
Code:

mke2fs -m 0 -c -c -v -L mirror -T largefile -j /dev/mapper/mirror

The extra '-c' calls badblocks in read/write mode. Id like this to use random data as this will be an encrypted volume.

man page for badblocks strongly discourages running badblocks outside of invocation through mke2fs. Is it possible to pass any additional options to badblocks through mke2fs such as a direct command like:

Code:

badblocks -c 10240 -w -t random -s -v ...

thanks

this is NOT the same question or duplicate posting but thanks for taking the time to reply.

unSpawn · 04-19-2008, 05:21 AM

With all due respect but yeah, it *is* the same because it's about invoking 'badblocks' for result of getting randomised data. Anyway:

Code:

dd if=/dev/zero of=/var/tmp/badblocks.dd bs=1M count=10
losetup /dev/loop0 /var/tmp/badblocks.dd
badblocks -v -w -t random -f /dev/loop0
# So what pattern we got?
strings -an10 /dev/loop0|sort|uniq|wc -l
1 # The pattern being a repeated single string of chars.
losetup -d  /dev/loop0
dd if=/dev/erandom of=/var/tmp/badblocks.dd bs=1M count=10
losetup /dev/loop0 /var/tmp/badblocks.dd
strings -an10 /dev/loop0|sort|uniq|wc -l
365 # The pattern being multiple strings of chars.

Of course this is a fast and shallow approximation of how you should test randomness for real, but it only was meant to show using 'badblocks -t random' is *not* a good choice.

XavierP · 04-19-2008, 08:10 AM

Moved: This thread is more suitable in Debian and has been moved accordingly to help your thread/question get the exposure it deserves.

archtoad6 · 04-19-2008, 09:28 AM

W/ all due respect, XavierP, why?

I have both badblocks & mke2fs on my MEPIS system, so I doubt this is a Debian-unique problem.

unSpawn · 04-20-2008, 06:45 PM

Quote:

Originally Posted by archtoad6

why?

On my request. Consolidating these threads keeps related or overlapping information together, which I think is important because the usage of 'badblocks -t random' should be avoided when preparing for disk encryption.

Molly · 04-20-2008, 07:52 PM

Thanks for all the help/pointers. Sorry for any waste of resources by having related questioning in another forum. As usual you are all extremely informative.

unSpawn · 04-21-2008, 10:30 AM

NP, NP. Hope you get your LUKS thing going now.