And if you’re concenred on data written on sectors since reallocated you should physically destroy the whole drive anyways. With SSDs this is even more complicated, but I like to keep it pretty simple. If the data which has been stored on the drive at any point of it’s life is under any kind of NDA or other higly valuable contract it’s getting physically destroyed. If the drive spent it’s life storing my family photos a single run of zeroes with dd is enough.

At the end the question is that if at any point the drive held bits of anything even remotely near a cost of a new drive. If it did it’s hammer time, if it didn’t, most likely just wiping the partition table is enough. I’ve given away old drives with just ‘dd if=/dev/zero of=/dev/sdx bs=100M count=1’. On any system that appears as a blank drive and while it’s possible to recover the files from the drive it’s good enough for the donated drives. Everything else is either drilled trough multiple times or otherwise physically destroyed.

hi, is the image AI generated?

I have an inch-high stack of platters now. Kind of interesting to see how their thickness has changed over the years, including a color change in there somewhere. Keep thinking I should bury them in epoxy on some table top.

For extra fun, you ca melt the casings and cast interesting shapes. I only wish I were smart enough to repurpose the spindle motors.

Like u/MrMcGasion said, zeroing makes it easier to recover original data. Data storage and signal processing is pretty much a game of threshold values. From digital world you might see 0 or 1, but in reality it’s a charge on a certain scale, lets assume 0 to 100%. Anything above 60% would be considered 1 and anything below 45% a 0. Or something like that.

When you do zero the drive, that means drive will reduce charge enough to pass the lower limit, but it will not be 0 on any account. With custom firmware or special tools it is possible to configure this threshold and all of the sudden it is as if your data was never removed. Add to this situation existence of checksums and total removal of data becomes a real challenge. Hence why all these tools do more than one operation to make sure data is really zeroed or removed.

For this reason random data is better approach is much better than zeroing because random data alters each block differently instead of just reducing charge by a fixed amount, as it is with zeroing. Additional safety is achieved by multiple random data writes.

All of this plays a role only on magnetic storage, that is to say HDDs. SSD is a completely different beast and wiping SSD can lead to reduced lifespan of the drive without actually achieving the desired result. SSDs have write distribution algorithms which make sure each of the blocks are equally used. So while your computer thinks it’s writing something at the beginning of the drive, in reality that block can be anywhere on the device and address is just internally translated to real one.

Just doing a single pass all the same like zeroes, often still leaves the original data recoverable. Doing passes of random data and then zeroing it lowers the chance that the original data can be recovered.

Here’s why not

There are many ways to setups full disk encryption on Linux, but the most common all involve LUKS. Providing a password at mount (during boot, for a root partition or perhaps later for a “data” volume) is a but more secure and more frequently done, but you can also use things like smart cards (like a Yubikey) or a keyfile (basically a file as the password rather than typed in) to decrypt.

So, to actually answer your question, if you dont want to type passwords and are okay with the security implementations of storing the key with/near the system, putting a keyfile on removable storage that normally stays plugged in but can be removed to secure your disks is a common compromise. Here’s an approachable article about it.

Search terms: “luks”, " keyfile", “evil maid”

store it in tpm

There’s many different ways with different performance tradeoffs. for example for my Homeland server I’ve set it up that I have to enter it every boot, which isn’t often. But I’ve also set it up to run a ssh server so I can enter it remotely.

On my work laptop I simply have to enter it on each boot, but it mostly just goes into suspend.

One could also have the key on a usb stick (or better use a yubikey) and unplug that whenever is reasonable.

I recommend using a different set of flags so you can avoid the buffering problem @thenumbersmason@yiffit.net mentions.

This next example prevents all of your ram getting uselessly filled up during the wipe (which causes other programs to run slower whenever they need more mem, I notice my web browser lags as a result), allows the progress to actually be accurate (disk write speed instead of RAM write speed) and prevents the horrible hang at the end.

dd if=/dev/urandom of=/dev/somedisk status=progress oflag=sync bs=128M

“oflag” means output flag (to do with of=/dev/somedisk). “sync” means sync after every block. I’ve chosen 128M blocks as an arbitrary number, below a certain amount it gets slower (and potentially causes more write cycles on the individual flash cells) but 128MB should be massively more than that and perfectly safe. Bigger numbers will hog more ram to no advantage (and may return the problems we’re trying to avoid).

If it’s an SSD then I issue TRIM commands after this (“blkdiscard” command), this makes the drive look like zeroes without actually having to write the whole drive again with another dd command.

I like it, then it’s even harder to know that it was encrypted in the first place. Thanks for that suggestion.

Oh, thanks for pointing that out. It’s been a while since I needed to erase a disk so I didn’t realize DBAN isn’t really a thing anymore.