45
Do I really have to use secure erase (sopuli.xyz)
submitted 2 months ago by to c/linux@lemmy.ml
39 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] 15 points 2 months ago* (last edited 2 months ago) (5 children)

Not really great on SSDs, though. It'll likely make them slower because now the controller thinks 100% of the memory is allocated. And some small percentage of the data will still be around, because they do overprovisioning.

Shouldn't matter for OP, though. If they set up LUKS properly, there's no way to decrypt the data.

But I mean secure wipe isn't hard... It's copy-pasting 2 more commands from the Arch wiki, compared to the dd command.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 5 points 2 months ago* (last edited 2 months ago) (3 children)

    some small percentage of the data will still be around, because they do overprovisioning.

    That's why I wrote "directly accessible data". You are certainly right that safely erasing all data on SSDs is hard to impossible to achieve, but so is the read access to it.
    That means if we disregard the drug distribution or similar scenarios, should be enough for the normal person.

    But I mean secure wipe isn’t hard… It’s copy-pasting 2 more commands from the Arch wiki, compared to the dd command.
    But it will take significantly longer (typically using /dev/random and multiple passes) without noticably increasing security for SSDs.

    It will have also have the same possible write-speed-penalty issue as the zero-overwriting, but this won't be OPs problem any more because he is selling the SSD.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 2 months ago* (last edited 2 months ago) (2 children)

    I don't think so. I did a secure erase on my Samsung SSD and I forgot how long it took, but I still remember being surprised how quick it was. I think it was quicker than overwriting the entire disk, even with zeros. I even double-checked whether it did it because it was done so fast. But yeah, it didn't return any data after that.

    I mean I'm generally not a big fan of all the compromises. Sure maybe most of it is deleted. Maybe it's not that easy to recover the rest of it. Maybe there's an easy tool out there... I mean the issue with it is, we have all kinds of personal data on our laptops. One nude left, or the tax filings document and you might be in trouble anyway, if you do some half-assed compromise. Maybe you'll give it to a regular person and nothing will happen... But I think generally it's not good advise to hand out to people. They might not be aware of all of the consequences, we might not know the full picture... And the exact phrasing is doing way too much heavy-lifting.

    Luckily there's a clever way. Use LUKS and encrypt your disk right from the start. (As OP did?!) That takes care of everything. And once you give it away, just discard all the blocks. Mainly as a service to the next person, because that's going to make the drive fast again. Should also be the fastest option, since SSDs do TRIMs all the time and are optimized for it. Quicker than a dd over the entire drive.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 2 months ago (1 child)

    Thing seems to be though, that OP did not use LUKS consistently, but mixed with unencrypted uses.
    In this case, fast, file-oriented secure-erase (or just throwing away all the LUKS headers, if the remaining partition was encrypted) might miss the remnants of old unencrypted uses.
    So, specifically in OPs case, I am not sure if there is another safe option than a full-device overwrite e.g. using dd.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •