Comments on: Various Ways To Shred A Drive https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/ Linux. GNU. Freedom. Thu, 11 Jan 2018 12:06:15 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42199 By: moeyebus https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-266180 Sat, 13 Aug 2016 09:08:21 +0000 http://pthree.org/?p=1793#comment-266180 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
done

]]>
By: How to Erase Sensitive Data from a Hard Drive | Ian Dunn, Seattle web developer https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115728 Thu, 28 Apr 2011 05:05:04 +0000 http://pthree.org/?p=1793#comment-115728 [...] Toponce has documented a way to overwrite sensitive data on a hard drive that is fast and gives you a running progress [...]

]]>
By: Aaron https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115568 Sun, 13 Mar 2011 16:04:48 +0000 http://pthree.org/?p=1793#comment-115568 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115563 Sat, 12 Mar 2011 18:23:22 +0000 http://pthree.org/?p=1793#comment-115563 ...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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115556 Fri, 11 Mar 2011 12:43:01 +0000 http://pthree.org/?p=1793#comment-115556 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115555 Fri, 11 Mar 2011 12:27:17 +0000 http://pthree.org/?p=1793#comment-115555 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115551 Thu, 10 Mar 2011 16:35:56 +0000 http://pthree.org/?p=1793#comment-115551 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115550 Thu, 10 Mar 2011 15:19:28 +0000 http://pthree.org/?p=1793#comment-115550 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115545 Thu, 10 Mar 2011 13:14:00 +0000 http://pthree.org/?p=1793#comment-115545 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115544 Thu, 10 Mar 2011 13:04:51 +0000 http://pthree.org/?p=1793#comment-115544 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115543 Thu, 10 Mar 2011 12:07:15 +0000 http://pthree.org/?p=1793#comment-115543 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 https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115541 Thu, 10 Mar 2011 11:33:33 +0000 http://pthree.org/?p=1793#comment-115541 Is there anything shreds unused space on a disk and leaves the rest of it intact ?

]]>
By: foo https://pthree.org/2011/03/09/various-ways-to-shred-a-drive/#comment-115537 Thu, 10 Mar 2011 10:22:22 +0000 http://pthree.org/?p=1793#comment-115537 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.

]]>