Creating a large file with random content: short-cut by copying

cryptsetupddencryption

Assume I want to create a large encrypted drive stored in a file using cryptsetup, the first step is to create a random file, assume this should be of size 3T:

dd if=/dev/urandom of=$FILE bs=1G count=3000

the above process can take really long time. I was wondering if the following short-cut makes any sense (from a security point of view, remember the goal is to create an encrypted drive stored in $FILE):

  1. dd if=/dev/urandom of=$FILE bs=1G count=1000
  2. Make 3 copies of the above file, each file has size 1T and has the same random content
  3. Merge the 3 files to create one random file of the target size of 3T

I guess that this procedure is not as rigorous as the data is a bit "less" random, but from a pragmatic point of view, is this a feasible solution (it would be almost 3 times faster)? Is this better than creating a 3T file full of zeros (using /dev/zero)?

Best Answer

/dev/urandom is way too slow for this amount of data.

If pseudorandom is good enough:

shred -v -n 1 /kill/me

If encrypted random is good enough:

cryptsetup open --type=plain /kill/me cryptkillme
shred -v -n 1 /dev/mapper/cryptkillme
cryptsetup close cryptkillme

Encryption is slow too but still order of magnitude faster than /dev/urandom.

shred should produce random looking data fast enough for any disk.

Also note that for this size you really should be using a regular block device, not a file. If the filesystem that hosts the giant file ever goes corrupt, you're looking at an unsolvable puzzle with lots of pieces as a file of this size will usually be severely fragmented.

If you stick to file anyway, you could consider not filling it with random data in the first place; you could use a sparse file instead and TRIM / punch_hole it to save storage space for unused areas.

If overwriting old unencrypted data was your goal, you'd have to overwrite all free space in the filesystem as well, not just the container file itself as you won't know whether that's allocated in the same place as the unencrypted data you wanted to get rid of.

Related Question