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?


The dd method will:

  • be faster because it does not need to traverse the directory structure
  • overwrite areas of the disk that are not currently occupied by files

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

In particular, shred may not end up doing anything useful at all on an SSD.

  • But dd with /dev/zero or /dev/(u)random will work on an SSD?
    – user71996
    Jun 10 '14 at 0:18
  • @user71996: Probably. But there's no guarantee, since an SSD might reserve some extra space for its own data management that isn't part of the disk exposed to the OS. Jun 10 '14 at 0:19
  • But that non-OS wouldn't have anything on it other than some default firmware and whatnot? No personal information, nothing?
    – user71996
    Jun 10 '14 at 0:20
  • 2
    @user71996 - if you're worried, there are more powerful tools.
    – mikeserv
    Jun 10 '14 at 0:28
  • 1
    No guarantees. An SSD can move sectors around if it needs to, some of the reserved space might be swapped with active space if the active sector has been written too many times. See Wear leveling for more information. Jun 10 '14 at 0:29


Whenever using 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.
  • Secure is a concept which has a meaning that is relative to the effort a person is willing to extend in getting the data out. dd and shred will 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.....

  • For performance, just use cat instead of dd. And, indeed, use zero instead of urandom. Note that the find … shred command is different and genuinely insecure: it doesn't erase the free space. Jun 10 '14 at 1:34

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 /dev/sda

This should be faster than having the kernel give you random data.


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

The dd method overwrites the whole disk.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.