Image of the glider from the Game of Life by John Conway
Skip to content

Various Ways To Shred A Drive

I've been tasked at work with shredding drives. Not physically, mind you, but digitally. Usually, I grab a copy of the latest version of Knoppix, boot up, pull up a terminal, and grab GNU Shred. Something like:

shred -n 3 -v /dev/sda

It works well enough. However, it doesn't display a real useful progress meter, other than how far it's done in the wipe, thus leaving it up to you to figure out the speed, while filling up your back scroll in the process. There must be a better way.

I used to "leave my mark" (much like a dog marks a fire hydrant), however, this is quite slow. There are other methods, such as using /dev/urandom, but the entropy from urandom relies on SHA1. While fast, it's not the speed demon that is AES or other algorithms. There's /dev/zero, but how do I get random bits from zeros? And more importantly, does it push the drive to it's bandwidth threshold? Of course, I've heard about DBAN, but I've had issues with it booting on certain hardware. Lastly, I would like to have a good progress meter as the data goes down on the drive.

Here's a solution that a friend of mine in an IRC channel suggested:

openssl enc -aes128 -k "foo" < /dev/zero | pv -trb > /dev/sda

The great thing with this command is two fold:

  1. It's fast. It pushes the drive to as fast as it can write data.
  2. It provides a convenient progress meter with "pv"

Again, I'm shredding drives with pseudorandom data. I'm not too concerned about the security of the bits going down on the platter. Per corporate regulation, I need to do 3 passes, and I'm confident that the bits coming out of the pipe from OpenSSL using AES-128 will be sufficient. So, for doing 3 passes, I can script it easily enough:

for I in 1 2 3; do
    openssl enc -aes128 -k "$I" < /dev/zero | pv -trb > /dev/sda
done

That works. 1 drive down, 24 to go...

If you have various ways you shred your drive, let me know, and I'll post it below.

{ 11 } Comments

  1. foo using Galeon 2.0.7 on Debian GNU/Linux 64 bits | March 10, 2011 at 3:22 am | Permalink

    Dude, don't trust that fucking FTL (flash translation layer) to erase your data. The research indicates that a lot of the underlying flash does not get erased. So much so that TrueCrypt recommends *NOT* to use encryption on flash drives at all because if you change the password then the old (potentially insecure) key is still present on the drive and can be used to decrypt the drive.

  2. Matt Parkins using Google Chrome 10.0.648.127 on GNU/Linux 64 bits | March 10, 2011 at 4:33 am | Permalink

    Is there anything shreds unused space on a disk and leaves the rest of it intact ?

  3. Cypher using Google Chrome 10.0.648.127 on Windows XP | March 10, 2011 at 5:07 am | Permalink

    Just for your info, the bits you are generating are highly predictable, as anyone can reproduce the exact same ciphertext using the same keys, which you've given here. Therefore it does not provide more security than using /dev/zero alone.

    You should use unpredictable keys and because they'll never be reused again, you can generate them once and trash them afterwards.

  4. Aaron using Google Chrome 9.0.597.84 on GNU/Linux 64 bits | March 10, 2011 at 6:04 am | Permalink

    First off, there's no evidence that data can be restored after wiping the disk with a single pass of zeros on today's drivers. The bit density is far too high. In the old days of MFM encoding and drives that were less than 1GB, sure- it was theoretically possible to retrieve overwritten data. Not today.

    Second, if the drive does get decrypted, zeros come out, not the overwritten data. And that's dangerous because...? Who cares if the bits are highly predictable? The fact is overwritting data, not encrypting it. I'm only using OpenSSL and pv, because of the speed and the progress meter.

    @Matt Parkins- Rather than sending the data to the drive, send it to a file. The file will continue to grow until you're out of disk space, and which point you can just delete it.

  5. Aaron using Google Chrome 9.0.597.84 on GNU/Linux 64 bits | March 10, 2011 at 6:14 am | Permalink

    Here are some links showing the near impossibility of restoring overwritten data:

    https://www.nber.org/sys-admin/overwritten-data-gutmann.html
    http://www.actionfront.com/whitepaper/Drive-Independent%20Data%20Recovery%20Ver14Alrs.pdf

    Personally, I don't buy into the conspiracy theories that the NSA/CIA/DOD/[insert your favorite government acronym here] has any additional computing power to read disk platters than standard data recovery specialists. And if the research shows getting the overwritten data is near impossible, with no evidence showing to the contrary, I'm good.

  6. Steven using Firefox 3.6.15 on Ubuntu 64 bits | March 10, 2011 at 8:19 am | Permalink

    An even better approach, depending on the drive type, is to use the secure erase command that is built into the ATA command set.

  7. Gary using Safari 533.1 on Android | March 10, 2011 at 9:35 am | Permalink

    for flash drives i suggest reading the paper linked to from here: http://www.schneier.com/blog/archives/2011/03/erasing_data_fr.html. it also has a sobering discussion of the secure erase command provided on some drives.

  8. Olle using Google Chrome 10.0.648.127 on Windows 7 | March 11, 2011 at 5:27 am | Permalink

    If you are worried about the key you could do:
    openssl enc -aes128 -k "$(head -c 2048 /dev/urandom | base64 --wrap=0)" /dev/sda

  9. Aaron using Google Chrome 9.0.597.84 on GNU/Linux 64 bits | March 11, 2011 at 5:43 am | Permalink

    I don't know why you would be- you're encrypting zeros. So what if an attacker decrypts the drive, and finds zeros? The goal is to overwrite data, which was accomplished.

  10. Jenna using Debian IceWeasel 3.5.17 on GNU/Linux 64 bits | March 12, 2011 at 11:23 am | Permalink

    ...faster... ???

    root@debian# time shred -n 1 /dev/sda6

    real 0m48.748s
    user 0m8.737s
    sys 0m6.332s

    root@debian:# time openssl enc -aes128 -k "foo" /dev/sda6
    pv: write failed: No space left on device
    error writing output file

    real 0m50.940s
    user 0m43.719s
    sys 0m19.093s

  11. Aaron using Google Chrome 9.0.597.84 on GNU/Linux 64 bits | March 13, 2011 at 10:04 am | Permalink

    Yes. Faster. You likely have at least 2 problems with your benchmark:

    1. You've filled up your disk cache before going to platter.
    2. If not filling up disk cache, then you've filled up RAM before going to platter.

    If you're going to run a benchmark on which is faster, shred at least 1.1x the amount of virtual memory on your system. For me, GNU Shred only pushes the disk to 90-95% it's theoretical bandwith. Running OpenSSL has shown consistent 100% performance out the drive- for all 24.

{ 1 } Trackback

  1. [...] Toponce has documented a way to overwrite sensitive data on a hard drive that is fast and gives you a running progress [...]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site