Securely shredding files

Question

Is the following a secure way of shredding files in *NIX systems:

shredder.sh

#!/bin/bash
# Define number of rewrites
COUNT=20
# Define file size
FILE_SIZE=`wc -c < "$1"`
# Begin rewriting file
while [ $COUNT -ge 0 ]
do
   # Write random data to file
   echo `dd if=/dev/urandom bs=1 count="$FILE_SIZE"` > $1
   COUNT=$(( $COUNT - 1 ))
done

Is the file being rewritten at the correct offset (starting point)?

Is there a shorter, better and more portable way of doing it?

Answer 1

No. Not by a long mile.

What you're trying to do is impossible, so it isn't surprising that you're failing. The most egregious problem is that you aren't even attempting to overwrite the file: … > $1 first truncates the file, which marks all of its blocks as free, and then the output of the command is written to newly-allocated blocks. There's no reason why the newly-allocated blocks would be the ones that were just allocated from the file.

If you ran dd if=/dev/urandom bs=1 count="$FILE_SIZE" of="$1" then that would overcome this obstacle. You could be sure that you've overwritten this copy of the file. But other copies of the file could exist elsewhere, such as:

• Temporary copies created when the file was generated or edited.
• Older versions, if the file was edited in the past.
• Backups that might have been taken by anyone with access to the file.
• Other copies existing in a snapshot of the filesystem.
• Other copies that might have been made inside the storage device. On SSD, erasing is an expensive operation (both in terms of speed and in terms of wear on the device), so writing new content from a sector actually just marks the sector as to be deleted later and writes the data in another sector.

The secure way of erasing data is to have encrypted the whole disk from day 1. Then, to be sure that the data is unrecoverable, you only need to wipe the key, which is generally stored in a well-defined location. Preferably, don't store the actual key on the disk at all: if the machine boots with human intervention, use a strong passphrase; if the key boots without human intervention, store the key on a smartcard or on a cheap USB key or SD card that you can destroy physically without remorse.

Beware that as explained above, merely overwriting data on an SSD isn't guaranteed to make it unrecoverable if the attacker has hardware access or can hack the SSD's firmware. You need to use the SSD's secure erase functionality, assuming it has one that works (sadly, some SSD models purport to have the capability, but it doesn't actually wipe the data).

Answer 2

Your script makes assumptions which are not necessarly true:

• Overwriting a part of a file will write the new data to the old sector
• This is especially not true for SSDs (look up wear leveling)
• You don't use a copy on write or overlay filesystem like btrfs or aufs

Edit: The above should only be considered a rough list of problems in your script. Allthough I am not fully ignorant at security questions there are many cases which are not handled here like temporary copies when editing your file, sending it to remote server, different caches, swap space, journals and many other things and things I don't know of.

Possible countermeasures (not (always) 100% secure):

• using shred, but is not intended for flash-based media like SSDs and not all filesystems including common ones like ext3
• using the tool from your SSD manufacturer, might not be available
• using full disk encryption before saving the file on it and also for the OS-partition, swap-partition, every other partition a (temporary) copy might be written and best also every other HDD/USB-stick/... . Back up all other data except the file you want to delete to an encrypted drive and then reformat and reencrypt all media having been in contact with the file (including the OS-partition) and put the other data back on the disk.