Prove that shred does not erase an SSD

applied · 35 min · Objective 3.6

Task

Demonstrate why overwriting is the wrong tool for flash, and cryptographic erasure is the right one. You will not have a real SSD to dissect, so you will reason from the mechanism and prove the reliable alternative end to end.

Steps

  1. Write a recognisable marker to a plain loop filesystem, delete the file, and show that its content is still recoverable from the raw device with grep -a MARKER /tmp/disk.img. Deletion frees the inode, not the blocks.
  2. Run shred on the FILE and show that on a copy-on-write or log-structured layer the original blocks may survive -- reason through why wear levelling means the overwrite need not land on the same cells a real SSD used.
  3. State the conclusion: shred was designed for magnetic disks where a write replaces a sector, and gives no guarantee on flash whose controller chooses where writes land.
  4. Now do it the reliable way. Create a LUKS volume on the loop file, write the marker inside it, and confirm you can read it back.
  5. Destroy the data by destroying the key: cryptsetup luksErase. Confirm the marker is now unrecoverable from the raw device, instantly, without overwriting the payload.
  6. Contrast the effort: erasing a 4TB encrypted disk this way is one fast command, where overwriting it three times is hours and still not guaranteed on flash.
  7. Note the hardware alternative for an unencrypted disk: the drive's own secure-erase or sanitize command, which the firmware can apply to every cell including those the host cannot address.

Verify

# after step 1, before shred: the marker is on the raw device
grep -ac MARKER /tmp/disk.img            # non-zero
# after luksErase on the encrypted volume:
grep -ac 'LUKSMARKER' /tmp/disk.img      # 0 -- key gone, ciphertext unreadable
cryptsetup open /tmp/disk.img lab 2>&1 | grep -qi 'not.*valid\|no.*luks' && echo "keys destroyed"

The plaintext marker being recoverable in step 1 and the encrypted one being gone after luksErase is the whole argument: destroying a small key beats overwriting a large payload, and on flash it is the only method that actually works.

Notes

The takeaway is architectural, not procedural: encrypt from first use, and decommissioning is a one-command key destruction regardless of the medium. Trying to shred your way to a clean SSD is effort spent on a guarantee the hardware will not give you.