My impression is that, if one wishes to be able to delete a certain file completely, without wiping an entire drive, one should never store it on an SSD. Is that right? Even with whole-disk-encryption, if the key is obtained, there seems to be no way to be sure forensic methods couldn't recover the file, short of issuing a firmware wipe command to the drive AND filling all of it with non-data (since the firmware command can't generally be relied on). So, if one wants the ability to delete something completely securely, and not the entire drive it's stored on, one should only store it on HDDs and USB sticks. Right?
1 Answers
It depends on your point of view.
There's the cryptographers point of view, who doesn't want even the shortest byte sequence to survive - after all, it could be an 8 byte password or a 128/256bit key (16-32 bytes). For cryptographers, even very short byte sequences are already considered critical.
And then there is the average user's point of view, who usually deals with documents, photos and videos in the megabyte to gigabyte range, and it's already a challenge to restore such files when accidentally deleted, even when not overwriting anything.
My impression is that, if one wishes to be able to delete a certain file completely, without wiping an entire drive, one should never store it on an SSD. Is that right?
The criticism regarding SSD stems from the complexity in its implementation. Basically the SSD is a black box, it has its own brain, makes its own decisions regarding where to store data, and when to erase it. As part of its wear-leveling mechanisms, it might even choose to relocate data on its own accord, and uses overprovisioning and other internal data structures that might be filled with data the user can't even access, much less reliably remove.
The HDD is a much more simple stupid storage medium in comparison. The HDD is more predictable to the user, and while it likewise keeps its sector reserves, there is a higher level of trust that these sectors will remain unused for as long as no surface defects / sector reallocation events are occuring.
It's no longer quite that clear cut with SMR drives that add additional caching mechanisms and optimizations. HDDs are getting smarter, too.
However, it's unclear how relevant these considerations are in practice. Things that cryptographers worry about might not necessarily be relevant to you.
In a data recovery situation, you have much higher chance of success when recovering files from HDD. With SSD, there usually is no hope at all. That's because SSDs wipe their data all the time.
With TRIM/discard being prevalent everywhere - when you run weekly fstrim
; when you mkfs
; when you lvresize
or lvremove
(if LVM is set to issue_discards=1
), or manually using blkdiscard
. The data is just gone and you probably won't be getting it back.
From a data recovery point of view, SSD is a huge headache. Data recovery loves the HDD, where data exists indefinitely until it's actually overwritten, and hates the SSD, where data is literally gone in an eyeblink, for the sake of performance.
So in a way, if getting rid of data is your goal, SSD is vastly superior to HDD.
Even with whole-disk-encryption, if the key is obtained […]
Making sure the key is impossible to obtain is the whole point of encryption. Once the key is known, it's as if the encryption doesn't even exist. If you see someone with a wrench, run for your life.
Full disk encryption is the best tool available to you if preventing access to your files, deleted or otherwise, is your goal. Using this tool correctly is another matter. Encryption can be broken easily if used incorrectly - all it takes is a keylogger or someone watching you type the passphrase. Even so, it's still the best you can do.
Encryption schemes like LUKS also protect against leftover small traces of data. LUKS doesn't store its keys as few bytes, but blows it up to hundred kilobytes of key material, from which the actual key is derived every time you enter your passphrase. That's also why LUKS1 reserves ~1MiB for its header, even ~16MiB for LUKS2.
It's meant to make the recovery of a wiped LUKS header quite unlikely if not altogether impossible, even if a storage medium like SSD were to keep around a few pages of data internally.
if one wants the ability to delete something completely securely, and not the entire drive it's stored on
These are at cross purposes to one another. It's more or less impossible to completely securely delete a single file without wiping the entire drive, or at least the entire free space.
The way we work with files - save, edit, save again, edit some more, save...
Every time you save a file, it usually gets truncated to 0 bytes and written anew, allowing the filesystem to store it anywhere in free space, in a completely different physical location. This creates additional copies of files, where even the filesystem itself does not know where old copies are located.
Tools like shred
or wipe
merely operate on the last known copy, making it useless for secure deletion. That's not even considering additional filesystem complexities like journals.
Other than wiping the entire drive with random data, and then reading it back to verify the very same random data was actually stored, thus constituting proof that the nominal storage capacity of the device was overwritten once, there is no way to securely delete it. That's about the limit of what you can do on your own, with any storage medium.
Since it's usually very impractical to actually do so, wiping free space is the next best thing, and SSDs (preferably those that support Deterministic read ZEROs after TRIM) provide that service for free at zero cost.

- 48,978
srm
command it is built for that ; The only question is does it have any special effect on a SSD or not – francois P Aug 02 '20 at 20:09