Comments on: Various Ways To Shred A Drive

By: How to Erase Sensitive Data from a Hard Drive | Ian Dunn, Seattle web developer

Thu, 28 Apr 2011 05:05:04 +0000

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

By: Aaron

Aaron — Sun, 13 Mar 2011 16:04:48 +0000

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.

By: Jenna

Jenna — Sat, 12 Mar 2011 18:23:22 +0000

…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

By: Aaron

Aaron — Fri, 11 Mar 2011 12:43:01 +0000

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.

By: Olle

Olle — Fri, 11 Mar 2011 12:27:17 +0000

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

By: Gary

Gary — Thu, 10 Mar 2011 16:35:56 +0000

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.

By: Steven

Steven — Thu, 10 Mar 2011 15:19:28 +0000

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

By: Aaron

Aaron — Thu, 10 Mar 2011 13:14:00 +0000

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.

By: Aaron

Aaron — Thu, 10 Mar 2011 13:04:51 +0000

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.

By: Cypher

Cypher — Thu, 10 Mar 2011 12:07:15 +0000

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.

By: Matt Parkins

Matt Parkins — Thu, 10 Mar 2011 11:33:33 +0000

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

By: foo

foo — Thu, 10 Mar 2011 10:22:22 +0000

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.