Media Sanitization – Easier, Faster, and Good Enough for Most of Us

Often, we’re told that if we are looking to secure data on hard drives or removable media, that we must encrypt that data. This will ensure that if our laptops or thumb drives get lost or stolen, or even when we are travelling abroad, that our data will be secured from prying eyes.

Well, if that is truly the case, then why are we expected to jump through so many hoops when it comes to media sanitization? Are we just looking to wipe the data from a drive, and then repurpose it to another user for further use? What is the value of the data (classification)? If we’re just looking to turn over the drive for re-use, then why are basic media sanitization standards so complex?

Government restrictions aside, the most accepted method of “wiping” a hard drive for re-use includes first writing all zeros to the drive and then writing random or pseudorandom data to the drive.

This is just too damn slow.

And, today’s media sanitization documentation reads like a conspiracy theorist’s manifesto:


So, what if we just encrypt the entire hard drive with a randomly generated key that never gets stored anywhere? Isn’t total drive encryption an already accepted method to secure our sensitive data from thieves and spies?

Of course, this is not an original idea:

As Bruce Schneier (noted security blogger and author of “Applied Cryptography”) states, “…. either a fully encrypted computer is secure — or it’s not. If it’s not good enough to consider the data gone – (if you encrypt the drive and destroy the key) – why depend on it to keep your data secure while it’s on your desk or wherever?”


There are several applications dedicated to the function of media sanitization. The most popular of these, and an accepted standard in the security community is a freeware program called, “Derek’s Boot and Nuke” (DBAN). While DBAN offers many methods to wipe a hard drive, it can take hours, and even days (depending on the size of the drive) to complete even the most basic hard drive wiping functions.

But, if we simply just encrypt the drive – a single pass encryption with a random key (or even a pseudorandom key) using a cryptographically secure algorithm – our data will be as secure as though it were wiped with a fancy multi-pass application.

Here’s a solution to the speed issue: Boot a linux kernel and run OpenSSL.

OpenSSL is native to the linux 2.6 kernel, so all one needs to do is a run linux live-boot from CD or USB drive, and then run OpenSSL from a command prompt.

The OpenSSL command-line binary that ships with the OpenSSL libraries can perform a wide range of cryptographic operations.

First, let’s look at some algorithm benchmarking in this arena. OpenSSL developers have created and included a benchmarking suite directly into the OpenSSL binary. It’s accessible via the “speed” option. It tests how many operations it can perform in a given time, rather than how long it takes to perform a given number of operations.

From the command prompt, run: openssl speed

There are two sets of results. The first reports how many bytes per second can be processed for each algorithm, the second the times needed for sign/verify cycles. Here are the results on an 2.16GHz Intel Core 2.

The ‘numbers’ are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md2               1736.10k     3726.08k     5165.04k     5692.28k     5917.35k
mdc2                 0.00         0.00         0.00         0.00         0.00
md4              18799.87k    65848.23k   187776.43k   352258.73k   474622.63k
md5              16807.01k    58256.45k   160439.13k   287183.53k   375220.91k
hmac(md5)        23601.24k    74405.08k   189993.05k   309777.75k   379431.59k
sha1             16774.59k    55500.39k   142628.69k   233247.74k   288382.98k
rmd160           13854.71k    40271.23k    87613.95k   124333.06k   141781.67k
rc4             227935.60k   253366.06k   261236.94k   259858.09k   194928.50k
des cbc          48478.10k    49616.16k    49765.21k    50106.71k    50034.01k
des ede3         18387.39k    18631.02k    18699.26k    18738.18k    18718.72k
idea cbc             0.00         0.00         0.00         0.00         0.00
rc2 cbc          19247.24k    19838.12k    19904.51k    19925.33k    19834.98k
rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00
blowfish cbc     79577.50k    83067.03k    84676.78k    84850.01k    85063.00k
cast cbc         45362.14k    48343.34k    49007.36k    49202.52k    49225.73k
aes-128 cbc      58751.94k    94443.86k   111424.09k   116704.26k   117997.57k
aes-192 cbc      53451.79k    82076.22k    94609.83k    98496.85k    99150.51k
aes-256 cbc      49225.21k    72779.84k    82266.88k    85054.81k    85762.05k
sha256            9359.24k    22510.83k    40963.75k    51710.29k    56014.17k
sha512            7026.78k    28121.32k    54330.79k    86190.76k   104270.51k
sign    verify    sign/s verify/s
rsa  512 bits 0.000522s 0.000042s   1915.8  23969.9
rsa 1024 bits 0.002321s 0.000109s    430.8   9191.1
rsa 2048 bits 0.012883s 0.000329s     77.6   3039.6
rsa 4096 bits 0.079055s 0.001074s     12.6    931.3
sign    verify    sign/s verify/s
dsa  512 bits 0.000380s 0.000472s   2629.3   2117.9
dsa 1024 bits 0.001031s 0.001240s    969.6    806.2
dsa 2048 bits 0.003175s 0.003744s    314.9    267.1

You can run any of the algorithm-specific subtests directly:

For instance, to test rc4 speeds:

openssl speed rc4


For the purposes of wiping data from a hard drive that would be unrecoverable from the average computer user, nearly any of these algorithms would be sufficient. But, if you are slightly paranoid (but not bound to government restrictions), RC4 should be sufficient (and benchmarks the fastest). Remember, we’re talking about sanitizing a personal or a corporate hard drive for the possibility of repurposing it – not hiding confidential secrets from potential “Enemies of the State.” The DoD standard of grinding a physical drive into metallic crumbs, and then heating up the fragmented bits into a molten lava is still the most secure method of hard drive sanitization where top secret data is concerned. The reasoning behind this is that rendering the drive into base metal slag will thwart most attempts to recover data through forensic analysis – even utilising an advanced technique to recover magnetic data on the drive called, “Magnetic Force Microscopy”.

But, to date, no one has proven that data that has been wiped with a randomized single pass can be recovered by Magnetic Force Microscopy, or any advanced methodology (this doesn’t rule out that certain advanced *and expensive* technologies to recover data really exist).

So, here’s how to wipe (or rather randomly encrypt) your data storage device:


Wiping the entire hard drive with an OpenSSL encryption routine:

After booting with a live linux distro, run from the command prompt:


dd if=/dev/random bs=1k count=1 | openssl enc -kfile /dev/fd/0 -in /dev/zero -rc4 -out filename

This will create a file and just keep filling it with data until the partition or drive is full.

You can simply delete the file after the operation is complete:

rm -f filename

If you feel the need to use another algorithm, replace “rc4” with your algorithm of choice.

You might also use a linux kernel module random number generator known as “frandom”: (there are some good benchmarking comparisons to other methods of drive wiping at this site).

Simple tests using this method of sanitization vs. the accepted standard drive-wiping applications show it to be (in some cases) 60 times faster.

Remember, the point of this is that if full drive encryption is considered “secure” for travel, loss, and theft, then it should be considered just as secure for media sanitization.


One thought on “Media Sanitization – Easier, Faster, and Good Enough for Most of Us

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s