Comments on: Various Ways To Shred A Drive Linux. GNU. Freedom. Thu, 15 Feb 2018 18:04:15 +0000 hourly 1 By: moeyebus Sat, 13 Aug 2016 09:08:21 +0000 I'd pefer doing this like that (less predictable bits):

for i in {0..3} ; do
openssl enc -aes128 -k "`head -c 60 /dev/urandom | base64 `" /dev/sda

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 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 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 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 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 Thu, 10 Mar 2011 16:35:56 +0000 for flash drives i suggest reading the paper linked to from here: it also has a sobering discussion of the secure erase command provided on some drives.

By: 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 Thu, 10 Mar 2011 13:14:00 +0000 Here are some links showing the near impossibility of restoring overwritten data:

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 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 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 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 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.