Should I use:
find / -type f -exec shred -uvz -nX
or just good old
dd if=/dev/urandom of=/dev/sda
Is one faster or more secure than the other?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
dd method will:
shred program repeatedly overwrites the file with random data, which may make it more "secure" than
dd, depending on your requirements.
However, the effectiveness of
shred depends on the filesystem. From the man page:
CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption.
shred may not end up doing anything useful at all on an SSD.
dd, use a large blocksize. As much as 4MiB is good. Using the default blocksize (512 bytes) will be significantly slower.
dd if=/dev/urandom of=/dev/sda bs=4M
If you are trying to overwrite data beyond any recovery, then, a simple
dd, like the above, and a hammer will do the trick. Without the hammer, you will always have bad blocks which may be readable, or SSD content, etc. that is not visible at the device level, but is there at the physical level.
If you are just trying to make it really, really, really hard, then don't bother with urandom, and just use /dev/zero
dd(properly sized) will be faster.
shredwill likely have the same approximate security from that perspective.
The cost of a new drive is probably less than the cost of more secure wipes, and, thus, the hammer is the right solution from that point on.
Update: Shred is pointless.
From the documentation for shred, it has a number of limitations:
Please note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. Exceptions include:
- Log-structured or journaled file systems, such as those supplied with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in data=journal mode), BFS, NTFS, etc., when they are configured to journal data.
- File systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems.
- File systems that make snapshots, such as Network Appliance's NFS server.
- File systems that cache in temporary locations, such as NFS version 3 clients.
- Compressed file systems.
You can throw in ext4 for that (which has journaling on by default).
Also, shred on your individual files will not go as far as removing all the relevant metadata from the file., You may have other hard-links, etc. pointing to the same inodes, and the metadata will still exist. Sometimes even knowing the existance of a file is a security problem.
Back to the hammer.....
Another option I just read about yesterday:
openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > randomfile.bin
Of course, you can replace
randomfile.bin with something like
This should be faster than having the kernel give you random data.
shred method only overwrites files that currently exist. It doesn't wipe files that have already been erased, including older versions of currently-existing files that happen to have been located in space that hasn't been reused yet.
dd method overwrites the whole disk.
dd method is unnecessarily slow because it overwrites with random data. Overwriting with zeroes is equally effective:
dd if=/dev/zero of=/dev/sda
You can also do this with
cat; it may be slightly faster.
cat /dev/zero >/dev/sda
The advice to repeatedly overwrite with random data rather than zeroes is something that was true for the disk technologies of 20 years ago — and even then, overwriting with zeros worked pretty well. With modern hard disks, overwriting with zeros is sufficient. See Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?.
SSD is a more recent technology than hard disks and less is known about its remanence after writes. There are to my knowledge no public reports of recovering data overwritten with zeros on any flash technology (I can't speak for government agencies — but they probably have your data already anyway). You may want to watch Secure wiping of EEPROM and flash memory for updates.
There is an added wrinkle on flash technologies that reallocate sectors (such as SSD drives): after overwriting the whole surface in software, there are sectors which are currently not mapped and still have their own content. These sectors cannot be read using the normal interface but might be read by probing inside the storage device. (As far as I know, this is a known technique, but ranges from moderately pricy to very expensive depending on the flash storage device model). To fully erase a flash drive, in principle, you need to issue a secure erase command; however [many devices do not implement this command correctly](ATA security erase on SSD), so always do a software wipe first.