Is the blocksize important when wiping a disk with dd and zeros

Question

I used
dd if=/dev/zero of=/dev/sda bs=4096
For wiping a disk. Can be the blocksize a security risk or is it just speeding the thing up.

Sorry for my bad english

Solution

Assuming you're just using a regular hard drive, the block size doesn't have any impact beyond performance.

If it's an SSD, it might have some security impact, but you can't really securely wipe an SSD using dd anyway, so it doesn't matter much (and if you just want to nuke everything to reuse an SSD, just use blkdiscard on it instead).

However, dd isn't secure, and it's not really high performance either, regardless of the block size. I would suggest looking into DBAN for wiping disks. In addition to having options for securely wiping traditional hard drives, it also includes a quick zero-fill mode that does the same thing you are with dd, but much faster in most cases.

Edit in response to questions about the security of dd for wiping disks

Using dd to wipe a hard drive isn't a secure method of wiping a disk for a couple of reasons:

• It doesn't wipe reallocated sectors. Almost any hard drive will eventually reallocate bad sectors. Once this happens, you can't touch those sectors at all unless you use some special firmware or completely bypass the disk controller (which requires soldering and a lot of somewhat arcane knowledge about the particular disk drive). This means that even if you fill every accessible byte of information with null bytes, any sectors that were bad will still contain what data they did when they got re-allocated (and in most cases, most of that data is recoverable). This actually applies to wiping via other non-physical methods as well, and as such if your disk has reallocated sectors and you need to make sure it's wiped, you need to use non-electronic means to do so.

• Overwriting a sector on magnetic media doesn't completely eliminate all traces of the previous data. These traces can't be accessed via the regular disk interface, but a well funded attacker can use an atomic-force microscope to observe these traces.

  To make an analogy, imagine using a pencil to write on a thick pad of paper. Once you tear off the top sheet, the impressions from writing on that sheet will still be faintly present on the next few sheets, and can be recovered using any of a number of reasonably simple means.

  This is why all major comercial disk wiping products make multiple passes using different patterns. Each subsequent pass weakens the traces of the original data, making it harder and harder to recover.

It's even worse for an SSD, even though they don't have the second issue listed above, because there are all kinds of other things that can get in your way:

• Most modern SSD's use a copy-on-write block mapping. This means that when you write to a given location as seen by the OS, you're not actually overwriting the data already at that location, you're writing to a new physical location in the device's media, and possibly copying some existing data from the old location.
• All modern SSD's, whether they use a copy-on-write block mapping or not, are over provisioned and do some form of wear-leveling. This means that at any given point in time, you can't actually access every single byte of flash memory on the device, and essentially causes the same issues that reallocated bad sectors do with wiping hard drives.
• Some SSD's use in-line compression to improve storage efficiency. This means that the exact data written in each block of flash memory may be different from what you are trying to write.
• Some SSD's use in-line deduplication to improve storage efficiency. THis means that any given block of data you write may not actually translate to writing anything at all to flash memory on the device.

Given all of this, if you actually care about security, don't try to wipe SSD's electronically (If it's a TCG Opal compliant SED however, and you trust the manufacturer, take that route), and don't' try to wipe hard drives electronically if they show any evidence of past bad sectors.

Comments

[AFH]

The only security aspect is that if there is a write error part-way through a write, then the rest of the block may not be initialised. The larger the buffer, the larger the uninitialised block. If you are erasing the disc before disposal, you should search for "erase mil std": among the utilities you'll find are wipe and secure-delete.

[davidgo]

How can DBAN be much faster at doing a zero-fill then DD? I'm highly skeptical of that claim.

[Austin Hemmelgarn]

@davidgo dd has to copy from /dev/zero for each block, DBAN reuses the same pre-filled buffer, so it only has to make one I/O call per block, compared to two and a memcpy for dd.

[davidgo]

@AustinHmmelgam - so? /dev/zero is a special file, its not like the OS is reading the contents from disk. As a quick test, reading 10 gigs from /dev/zero and writing to /dev/null using dd with 1k blocks took 9.5 seconds on my laptop. Doing the same thing with 4k blocks (ie 40 gigs) took 11.1 seconds, and 40k blocks (ie 400 gigs) took 37 seconds - this tells me that reading from /dev/zero is not a significant source of resource.

[Austin Hemmelgarn]

@davidgo Even though its a special file, there's still a a system call involved, which means at least two context switches. There's also the matter of buffer handling (DBAN allocates a single buffer, fills it with zeroes and then repeatedly calls write with that see buffer as an argument, while dd has to call read for each block and then write for each block because it has to handle copying from regular files).

[Hashim Aziz]

For what reason do you say dd isn't secure? What could be more secure than zero-writing the disk?

[Austin Hemmelgarn]

@Hashim Updated my answer to expand on the security aspects abit more.

[Johnny Wong]

A remark on security: According to modern NIST standard (in Appendix A), one all-zeros write pass should be usually sufficient for (modern) ATA Hard Disk Drives (at least non-SSDs). Another quote: The U.S. National Security Agency published an Information Assurance Approval of single-pass overwrite, after technical testing at CMRR showed that multiple on-track overwrite passes gave no additional erasure. (with a ATA hardware-level "secure erase" command) from section "Number of overwrites needed" at en.wikipedia.org/wiki/Data_erasure

[mniess]

Regarding the second issue of overwriting magnetic media. It's a myth that has long been debunked. It came from the original paper about securely wiping harddrives in which the author assumed that things you can do with magnetic tapes apply to harddrives as well. That doesn't work, though. You can recover a specific bit with a probability of 0.2 (20%). For consecuitive bits the probabilities multiply So the probability to recover a single byte is 0.000256%. en.wikipedia.org/wiki/…