[SLL] Full-disk Encryption: How to randomize a disk

[Derek Simkowiak]

    I just wasted a couple of hours finding this, so I wanted to share.

    If you use full-disk encryption, you should first fill the entire 
drive with random noise.  The reason is, once you start using your disk 
(w/encryption), it will be impossible to distinguish your encrypted data 
from the pre-existing random noise.  That makes it much, much harder to 
figure out your passphrase (or other decryption key) using cryptanalysis.

    Historically, I've used /dev/urandom for this purpose, with a 
command like:

# Wipe your disk with random-enough noise:
dd if=/dev/urandom of=/dev/sdX bs=1M

    That is a little slow (it'll take a few hours), but it works for a 
modern workstation with an ~80Gig disk drive.  It is one of the methods 
recommended in the "Encrypted Device Using LUKS" HOWTO document.

    This week I've been setting up an encrypted backup solution for a 
client, with a large 2TB drive.  After letting the above dd command run 
overnight, it was only about 15% done.  I.e., Way Too Slow.  So I had to 
find something faster.

    First, I tried "shred", with just a single random pass.  I'd read a 
forum posting that it was much faster than dd with /dev/urandom.  It's 
not.  (In fact, it uses /dev/urandom by default.)

    Next, I considered "badblocks" with the "-t random" option.  That 
uses the libc "rand()" function, which is very fast, but very 
non-random.  I saw a forum posting online where someone demonstrated 
that this produces predictable, repetitive results -- meaning, no 
protection against cryptanalysis.  I scrubbed this idea as "not 
sufficiently secure".

    Finally, I stumbled across a solution on the Gentoo wiki:

http://en.gentoo-wiki.com/wiki/Secure_deletion

    The wiki article is talking about overwriting sensitive data with 
random noise, which is basically the same problem as populating a blank 
drive with random noise.  It had the commands I needed.

    The solution is to create a temporary encrypted device across the 
entire disk.  Then, you can fill the encrypted device with zeros.  Those 
zeros will be encrypted by the kernel's kcryptd, resulting in something 
that looks exactly like random noise (even though you could, 
theoretically, decrypt all that "random" noise and get a bunch of zeros 
back). 

    Here are the commands (WARNING: Don't run these!  They'll wipe your 
drive irrevocably!):

# First, create the encrypted partition.  Note that the decryption key is
# /dev/urandom, meaning, you'll never know what the key is, and you'll
# never be able to decrypt this one-time device.
cryptsetup create random_sdx /dev/sdx -d /dev/urandom

# Next, fill your encrypted partition with zeros... which look just
# like random noise once they're encrypted:
dd if=/dev/zero of=/dev/mapper/random_sdx bs=1M

# Finally, clean up the encrypted device:
cryptsetup remove random_sdx


    This process is much, much faster (something like 1000% faster for 
my big 2TB backup drive).  It's only about ~7% slower than running "dd 
if=/dev/zero of=/dev/sdx bs=1M" on an uncrypted disk, depending on your 
CPU, disk I/O, etc.

    As a final tip, you can monitor the progress of your long-running dd 
command by sending it a USR1 signal.  For example, "kill -USR1 3050" 
will cause dd to print out something like:

73157+0 records in
73157+0 records out
76710674432 bytes (77 GB) copied, 2868.97 s, 26.7 MB/s

    ...and then the dd will continue running until completion.

    Hope this helps someone else!


Thanks,
Derek