I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime. As far as I know, it’s good practice to secure-erase it, but I’m too lazy to reinstall the OS on it (I already did it once). Is it really needed?
Follow the steps here to perform a secure erase that resets the cells and wipes any on-device encryption keys:
https://wiki.archlinux.org/title/Solid_state_drive/Memory_cell_clearing
You can do this from a live-boot environment if you wish. I would very strongly recommend disconnecting ALL other drives before performing this step as the best precaution against accidentally nuking the wrong drive. However if you choose to do this with other drives connected triple check you have the right drive selected before each step.
run photorec on it after trashing the luks header if you want to be sure
You said that:
I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime.
This leads me to assume that it is not now? Is this the case? If it still has LUK2 on it, you can run cryptsetup-erase on the luks2 container. This won’t wipe any unencrypted data, though.
One needs to be careful and avoid block level wipes wherever possible for SSD as this will wear it out quicker. Obviously, if you have sensitive data unencrypted, you may have to. Shred is your friend, here. It works on entire devices as well as individual files. The individual files option is preferable if you the sensitive data is at known locations.
Does shred work on journaling file systems?
I doubt it. I think some filesystems have mount options that disable the journal for that session.
Huh, pretty serendipitous exchange. I found this: https://www.webconn.tech/kb/disable-or-enable-journaling-on-ext4-filesystem
Secure erase just drops the ssd controllers table of where logical blocks are in the physical memory and trims the disk. Which is good and you should do.
That means a person would have to address the memory directly with flying leads or a bed of nails or something. Or have special software that makes the controller tell them what’s on each physical block and then put that data together into a bunch of files.
If that worries you, do dd if=/dev/urandom of=/dev/<disk> before you secure erase.
Then everything on the drive will be random static before the secure erase drops the block table and trims, so even if someone uses magic power to read the block contents directly they just get to see static.
That has the benefit of speeding up the drive by resetting read fatigue at the expense of one layer of writes which is always worth it.
Useless use of dd. cat or cp are better suited in this case.


