51–60 of 117 posts
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.
Two issues with that - you have to make sure you dispose of the key(s), and this doesn't let you securely erase just part of the drive.
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.
Earlier quoted context omitted.
TRIM and FDE isn't perfect though as it leaks information about what parts have been written etc. And if you turn off TRIM you get a massive performance decrease.
Why would someone turn off TRIM?
The disadvantages are massive, such as significant slowdown when the drive gets filled. Yet the creators of dm-crypt are paranoid about enabling it by default:
https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar...
I couldn't understand ref 3: https://web.archive.org/web/20160709174950/http://www.saout....
Ref 4: "you have an information leak where filesystem-discarded blocks (by TRIM) can be identified by an attacker with low effort"
https://web.archive.org/web/20160709183108/http://www.saout....
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.
Earlier quoted context omitted.
Two issues with that - you have to make sure you dispose of the key(s), and this doesn't let you securely erase just part of the drive.
3. Technically someone could uncover a flaw in whatever encryption you used.
As others have mentioned, use encryption. But that has gaps as someone can hold onto the drive and wait for impossible to break to become somewhat expensive to break to broke by mistake through bad encryption implementation . Put the encrypted drive into a hydraulic press and flatten it into a thin sheet, then run that sheet through a chop saw, or just use tin-snips if your hydraulic press was powerful enough. A hydr…
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, reading the raw data of an SDD would just produce garbage. You would need to also extract the encryption key from the SSD controller. Given this encryption isn’t meant to be secure, it’s quite possible to extracting that key is quite easy. But I believe that secure erase on SSDs is achieved by simply rotating the encryption key used for wear levelling, so maybe it’s reasonable well protected.
I would expect an SSD to quite aggressively erase TRIMed blocks where possible. Erasing a block of flash memory is about 10x slower (2ms) than writing to flash memory (200microseconds), so there’s quite a large performance hit once a drive runs out of empty blocks and needs to start erasing blocks in the write path.
Overall I suspect that simply TRIMing most SSD is secure enough for most applications. At least secure enough for anyone that even asks the question “is TRIMing secure enough”. For everyone else, you either don’t care at all, or your really care, in which case you’re using multiple layers of security such as full disk encryption, secure SSD erase, and shredding drives already.
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.