I'm looking for a faster way to prepare hard disk drives for encryption (dm-crypt, LUKS) writing random numbers to the entire disk. I'd like to know how other slackers handle this and solicit suggestions.

I have been using the old, usually good enough, standby ...
This worked fine for a single 120GB drive. I just let it run overnight and built the machine the next day.

But /dev/random and /dev/urandom aren't good sources for generating large numbers of bits. When I install five 2TB drives in a system this takes a loooong time. I have to start preparing the disks more than a week before I can build the system.

Is there any way to speed this up when booting then installing a system from a Slack CD/DVD?

--------------

These are the options I can think of in order of preference.

1. Boot an empty system from a Slack CD/DVD and use the resources available to prepare the disks for RAID & encryption Just like I do now but only faster.

2. Boot a standalone utility/OS from CD to write non-repeating random number sequences to the disk (quickly). Perhaps on option in a disk erase utility?

3. Boot from a Slack CD/DVD as #1 above but then mount a CD or USB flash drive with an utility to to the job (quickly write random numbers to hard disks) and works in the environment currently running.

4. Install Slack from CD/DVD then install the libraries/utilities/hardware needed to prepare the disks (e.g. gpg, openssl, haveged, rng-tools, hardware entropy generators, etc). Then re-install the final version of Slack on the now prepared hard disks.

5. First attach each disk to a separate "disk preparation" computer already built and configured for this job. Then transport the disks and install on the new machine.

6. Ignore disk preparation and hope the perpetrator isn't sophisticated enough to take advantage of knowing which sectors of the disk are written and which ones aren't.

---------

I'm guessing that option # 1 doesn't offer the resources to speed things up (increase entropy). Please speak up if I'm wrong on this, as this is my preference.

Perhaps there is a standalone utility (option # 2) out there that I can use. The random number sequence run length should be large before repeating (>2TB) or else the utility should re-seed the generator before the sequence repeats. (even though /dev/urandom with a depleted entropy pool may produce repeating sequences now)

Does anyone know of a standalone utility that boots from CD and properly prepares the disks for encryption? (I know ... not really a Slackware question)

I'm normally not in a hurry when I work with computers, but working with large capacity disk drives now encourages me to look for faster methods of disk preparation.

Thanks.

The way I do it is to fill the device with zeros that have been encrypted with a random key. For a decent encryption algorithm, the result will be indistinguishable from random numbers.

1 members found this post helpful.

Interesting approach and it works with just booting the Slack install disk.

What kind of speed do you see with this method. Is it about the same as writing /dev/zero to /dev/sdx?

Since all the data is identical (all zeros) do you know if there is a problem with the numbers produced having repeating sequences when filling up large disk drives?

You can use 'wipe' to wipe the disk faster than /dev/urandom. It uses the MT algorithm with a very large period and is seeded before it ever reaches it. There is also an SIMD based MT implementation:
http://www.math.sci.hiroshima-u.ac.j...FMT/index.html
You would have to write your own seeding program, which I did, and it is faster than 'wipe', but probably won't make a difference for a HDD.
http://www.linuxquestions.org/questi...-c-4175434150/
I used it for different purposes.

1 members found this post helpful.

Thanks for the suggestions/links.

The SFMT program has a very large period and doesn't appear to need re-seeding before filling up many disks.

With a less than top-of-the-line processor (AMD E-350 dual-core 1.6GHz) I get about 40 MB/s writing to an SSD. That's over 10X the speed I get writing from /dev/urandom to the same device.

Any reasonably recent cryptsetup should not default to a cipher whose initialization vector would repeat while filling a large drive. Personally, I've never needed more than the 2TB that the "plain" IVs can cover.

A 10 times increase would bring my current large-disk scenarios down to less than a day for disk preparation. A tremendous improvement. Although I usually use magnetic drives and only use SSDs occasionally and with smaller capacities.

The best I can hope for is a number generator that runs fast enough so that the disk drives are the bottleneck.

Note that I've gone back and fixed those bad cryptsetup args in #2.

In the old days... I would encrypt my drive and then append a text file to itself until the drive ran out of space. Not as fancy as some of the MIT or NSA utilities, but I figured after someone found the 1000th text listing of "Hi my name is JJ" they would give up.

-JJ