81–90 of 117 posts
Earlier quoted context omitted.
Hydraulic press is too obscure, .45 ACP works just as well. But it depends on your risk profile, for most people a wipe-and-reuse is going to be fine, especially if the "reuser" is already a trusted entity.
I guess used microwave would be easiest and cheapest option for SSDs
Somethings not mentioned in the article, but are pretty relevant. Modern SSD controllers encrypt all data by default. Not to increase security, to improve wear levelling. Encrypted data should be effectively random data (that’s what good encryption aims to produce). So encrypting the data ensures that patterns in data written to the SSD don’t end up creating uneven wear patterns in the flash chips. As a consequence,…
But the "encryption" need not be cryptographic strength for this, so it might be reversible even without the key. Consider an old cypher with a small key for example.
Or you encrypt the entire drive. Then the secure erasure is a matter of throwing away the keys, and you don't have to bother with thinking through your threat model.
Throwing away the keys is surprisingly hard to do. Say you have one root key and you derive per-file or per-block keys using various metadata (inode numbers, generation numbers, block addresses, whatever). You can't throw away derived keys though! Or say you generate random keys per-file and you store those somewhere (it's annoying to have to store them). Now to throw those keys away you need to re-write the blocks c…
Well, yeah, that's why I said you encrypt the entire drive. If you do things that make it hard to throw your keys away, then it's gonna be hard to throw your keys away.
Unrelated to trim, but for some reason when I used secure erase on an SSD with a ZFS pool, the pool was still able to be found by ZFS. That shouldn't be the case, right?
I think ZFS identifies drives by their serial number. So you can erase a drive in a pool, and ZFS on that machine will still recognise the drive based on its serial number, and know its pool membership. ZFS should then throw all kinds of errors once it notices that all the super locks and other FS metadata is missing. But a scrub should cause ZFS to simply fix that via normal resilvering.
Earlier quoted context omitted.
Hydraulic press is too obscure, .45 ACP works just as well. But it depends on your risk profile, for most people a wipe-and-reuse is going to be fine, especially if the "reuser" is already a trusted entity.
A firearm is a silly tool for this. A hammer (optionally combined with good nails) can do substantially the same thing to all relevant materials (aluminum, glass, ceramic, silicon, plastic), but cheaper and more safely.
Earlier quoted context omitted.
> the random device /dev/zero would be sufficient. Also easier to confirm things worked (if desired) since you know what to expect on read-back.
You're assuming the drive doesn't do something smart when it detects it's being filled with zeroes. It could at least in theory decide to do the same thing it does when you TRIM a sector.
Write 5 gig of zeros? OK! You just got more drive reserve capacity!
Full disk encryption that are decrypted using a U2F security keys are now here (latest LUKS/systemd allows to do that). And Yubikey don't leak secrets. If your system is compromised to the point that someone gets access to the full disk decryption key protected by your Yubikey, you've got bigger problem than securely erasing the disk. Need to recommission a disk? dd to the disk because why not. Some sectors didn't ge…
and is there something that prevents someone from brute forcing that pin/password if they have access to the Yubikey?
I've not used a Yubikey in this way before, sounds really neat.
If your bios is not allowing secure ATA functionality ("frozen" in hdparm) try doing a pm-suspend and then waking back up. For me this unfroze the drive, although I have no idea why. I was then able to mess with ata security options, run secure erase, etc.
I think the pm-suspend/wake 'reinits' (for lack of a better word) the drive and doesn't set the magic frozen bit.
I'd love to know from someone who has the actual tech details vs. my half-remembering an explanation from a wiki.
Earlier quoted context omitted.
All those articles are very theoretical, in reality 1 pass of dd /dev/zero makes things unrecoverable, for recent SSD since trim is enabled by default you can't recover anything, I deleted a document by mistake on an SSD and it was impossible to get back, the moment I pressed delete on windows the trim command was sent and everything was erased on the ssd. Pro recovery compagny that are not shady know that SSD recove…
So ... you didn't read the article then?
From my experience it's impossible.