Note that most of the following commands need to be run as root.

Randomness

Begin by writing random data to the disk, this is verry important, if it is skipped the security might be severly compromised. A high-end CPU (sandy bridge) can generate about 8 MB/s in pseudo-random data (/dev/urandom), per core (HT is of no help). With that speed it takes a couple of days to randomize a normal disk. /dev/random is way to slow to be practical (would take thousand of years to fill any disk today), badblocks is an alternative, however I don’t recommend using it as I suspect it is not truly random (might for example be the same random pattern repeated over and over again).

Note

Ivy bridge (the next generation of CPUs from intel) is said to have a new type of random number generator which apparently is magnitudes faster than the one in current CPUs.

This does however have some security implications, since the RNG is simply a hardware blob it is difficullt to know how good the entropy is and if it can be trusted

A lot of the information on this page is taken from here. However the site might go offline in the near future.

Badblocks

# badblocks -c 10240 -s -w -t random -v <device>

Where -c sets the block size, -s shows the progress, -w sets badblocks to write mode, -t specifies the test pattern, in this case random and -v is verbose, naturally.

This usually takes a couple of hours, as this process is IO-bound, and not CPU-bound.

/dev/urandom

# dd if=/dev/urandom of=<device>

This will read from /dev/urandom and write it directly to <device>.

When done, we need to create a partition with fdisk

To paralize the randomisation we can use several instances of dd (which will be run on diffrent cores). We can also have data being transmitted over the network.

# dd if=/dev/urandom of=<device> count=400000000 &
# dd if=/dev/urandom of=<device> count=400000000 seek=400000000 &
# dd if=/dev/urandom of=<device> count=400000000 seek=800000000 &
# dd if=/dev/urandom of=<device> count=400000000 seek=1200000000 &

The above commands will start 4 instances of dd (hopefully one per physical core). If we want to utilize other computers on the network, we can use netcat, though remember that netcat is unencrypted which means you need to be SURE no attacker can listen in on the connection.

# nc -l 10000 | dd of=<device> count=400000000 seek=1600000000 &
# nc -l 10001 | dd of=<device> count=400000000 seek=2000000000 &

And on the remote machine you would start two instances of dd and pipe them through nc like this:

$ dd if=/dev/urandom | nc <machine_ip> 10000 &
$ dd if=/dev/urandom | nc <machine_ip> 10000 &

When you want progress you can send a SIGUSR1 to the dd processes, note though that you need to have access to the terminal from which you started dd (and haven’t disowned them), otherwise there is nowhere for dd to output the status too.

Cryptsetup

# cryptsetup --verbose --verify-passphrase luksFormat <device>

I normally have the pass-phrase just in case I lose access to the key file:

# cryptsetup luksAddKey <device> <new key file>

Now we open the luks device in order to format it.

# cryptsetup luksOpen <device> <device name> --key-file <key file>

This will create a new entry in /dev/mapper on which we will write the new filesystem.

Creating filesystem

Writing the filesystem:

# mkfs.ext4 -L <device label> -m 0 /dev/mapper/<device name>

The -m switch specifies how much space will be reserved for the super-user, as my drives is mostly for storage, he dosent get any.

Now we just need to make sure the device is added automatically when we boot. We need to edit (add a new line) both /etc/crypttab and /etc/fstab in order to get this to work. The first file opens the luks devices and the second mounts the unencrypted devices in the filesystem.

/etc/cryptsetup:

<device name>    <device path>        <key file>         luks

/etc/fstab:

/dev/mapper/<device name>     <mount point>      ext4      defaults      0   2

A tip is to get the device path from /dev/disk/by-id/, because then it doesn’t matter where on your motherboard/controller card the drive is connected.

That should be all you need to know to get a proper setup with encrypted drives.