61–70 of 117 posts
Earlier quoted context omitted.
Delete all the files then "dd" from the random device until the drive is full? Must we always jump straight to the hydraulic press?
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.
https://en.wikipedia.org/wiki/Thermite Securely erases all known forms of electronic data storage. Cheap, reliable, fun for the whole family!
> Flash storage, unlike traditional hard drives, can really be completely and irrecoverably erased, with no lingering magnetic ghosts that a sufficiently determined person could in theory reconstruct. I think people vastly overestimate the possibility to recover any data from a wiped HDD. See for example this article by SANS [1]. To recover a single bit you have a better chance of flipping a coin to see if the bit wa…
This can't be true. Any method must be at least as good as a coin toss. If it's worse you can just bit flip the result and end up better than the coin.
Edit: And of course even a high of 92% is abysmal for a single bit, since the combined odds of multiple bits quickly goes to zero for any sizable amount of data.
> Flash storage, unlike traditional hard drives, can really be completely and irrecoverably erased, with no lingering magnetic ghosts that a sufficiently determined person could in theory reconstruct. I think people vastly overestimate the possibility to recover any data from a wiped HDD. See for example this article by SANS [1]. To recover a single bit you have a better chance of flipping a coin to see if the bit wa…
Pro recovery compagny that are not shady know that SSD recovery with TRIM is impossible.
Earlier quoted context omitted.
3. Technically someone could uncover a flaw in whatever encryption you used.
Once you have an attacker with that kind of technical skill, you are in a totally different world.
That shouldn't be the case, right?
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?
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?
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.
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.
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 containing them. If there's any behind-the-scenes copy-on-write going on then re-writing a block doesn't necessarily lose its old contents.
The only thing that's easy to throw away -maybe- is the top-level / root keys. But that means deleting the entire filesystem.