Hacker News new | past | comments | ask | show | jobs | submit login

dd if=/dev/urandom of=/dev/sdx bs=1024 count=(size of drive in K)

Do it for as many times as you want.

As flash drives do automatic wear levelling and remapping of bad sectors, some people worry that their data might remain on the flash, in sectors they can't read or write because of those features.

If someone is that concerned perhaps they should have been using an encrypted volume on the flash drive in the first place.

This is true. However you have to trade off the risk of an entire volume failing due to a partial cell failure which would mean only the loss of a single file if it wasn't encrypted.

This device was stored securely in a fire safe at home, not used as a portable device.

I've worked on SSD firmware for many years and for most of the implementation algorithms I'm aware of, if you write the full drive range twice with random data, that should overwrite all the original data.

"Most" implies "not all"…

I find these arguments funny

Where do you think the drive will keep data after saving an amount of data multiple times the size of the drive?

What you describe might happen if you "delete" a file and save a new one. Then it is most likely recoverable.

Not all drives allocate all flash cells for storage. Some are metadata and some are spare so they wear leveling has some headroom. In fact if you use Samsung disks you can leave some headroom extra on the device to handle these scenarios.

Even ignoring that substantial problem, dd also tends not to work when the hardware is broken. (And you can't be sure it's sufficiently broken to prevent data recovery.)

Yes. Incidentally when you get a nice fresh SAN for example, you can dd 20TiB volumes in a couple of seconds. Doesn't mean they have been written to.

> Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive.

Overwrite you whole SSD 10 times I doubt anyone but the most serious attacker can find anything, and even then.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact