5

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)?

  • 1
    Why don't you just run three parallel dd processes, save to different files and then merge the files? – terdon Sep 11 '15 at 15:49
  • 1
    I suspect that the amount of randomness is the limiting factor and not the speed of file creation. – Thomas Weinbrenner Sep 11 '15 at 21:22
  • 1
    If you actually care about the security of the data you plan to store in this encrypted image, you should really leave this site and go read the docs. Read the HOWTOs, the FAQs, and, as much as possible, use standardized tools and commands. Even small mistakes can significantly weaken the encryption, and people who aren't experts will often give outdated or just plain bad advice. You can probably find some good info on the Debian, Ubuntu, Arch, and Gentoo wikis, as well as the cryptsetup and LUKS man pages and readmes. – blujay Sep 12 '15 at 1:21
  • 2
    If, after all that, you're not confident, then don't "roll your own." Use your distro's built-in tools for encrypting /home or an individual user's homedir. – blujay Sep 12 '15 at 1:21
  • 1
    2 more tips from man cryptsteup: 1. If a partition was previously used, it is a very good idea to wipe filesystem signatures, data, etc. before creating a LUKS or plain dm-crypt container on it...For a full wipe, overwrite the whole partition before container creation. If you do not know how to to that, the cryptsetup FAQ describes several options. 2. Unless you understand the cryptographic background well, use LUKS. With plain dm-crypt there are a number of possible user errors that massively decrease security. While LUKS cannot fix them all, it can lessen the impact for many of them. – blujay Sep 13 '15 at 3:09
2

/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.

  • thank you, could you elaborate on how to use a regular block device? Do you mean a partition of a disk? In the shred example, what is /kill/me? A large file (e.g 3T) or a block device? – Mannaggia Sep 11 '15 at 16:45
  • /dev/urandom is pseudo random (after you exhausted the entropy pool). – Thomas Erker Sep 11 '15 at 16:48
  • 1
    @ThomasErker On Linux, random and urandom give the same output. The only difference is, random blocks when the entropy reaches the threshold, while urandom never blocks. They both output CSPR numbers from the same pool. See LWN for more details. – blujay Sep 12 '15 at 1:13
  • @frostschutz 1. There's nothing wrong with using a loopback image for an encrypted filesystem. If your disk corrupts the filesystem, you're toast either way. 2. Be very careful giving out crypto advice. It's a very complex subject, and almost no one is truly an expert. In this case it's definitely not a good idea to suggest that someone not fill the image with random data before using it. That significantly weakens the usefulness of the encryption, because it makes it trivial to see what parts of the image have actually been written to. – blujay Sep 12 '15 at 1:17
  • 1
    @frostschutz I am not a cryptographer, and neither are you. Those who are say not to do that. So please stop giving out known-bad advice and encouraging people to do things which weaken encryption and make it easier for attackers to break. You can google up plenty of examples that tell you why you should always initialize an image with random data before using it as an encrypted disk, such as this article. If you care enough to use encryption, care enough to do it properly. – blujay Sep 13 '15 at 2:59
3

Answering the last part of your question: is your approach (using the same random data three times) better than using zeros.

Not really, it's almost the same. With three identical random parts, each block on your device is part of a triple of identical blocks. An attacker can therefore map out the blocks of your device that have changed and that is the same information the attacker gets from a zero'ed device. Only when your device is so full that each triple has three different blocks, this breaks down.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.