One has to find the right balance between security and comfort, and this entirely depends on the threat model one has. Nowadays, I will always enable full-disk encryption on all of my devices, even if I then decide to store the keys in TPM and unlock the disk at boot.
I have at least 5 half-broken HDDs sitting around, completely unencrypted, I have no idea if they still work, but they are surely full of private data that I would like to have purged. I fear mechanical destruction might be the only solution for some of them, but just wiping them manually is more effort than doing nothing, so I guess they will still be around for some time. And with SSDs, there is no reliableway delete all data.
With encryption? Just delete the key and you are done.
The threat model changes in the future? Easy, the data is already encrypted.
I thought there was a table method of “destruction”. Like you delete or destroy the table of allocation. Even though the data is on the SSD, its not contiguous like HDD and so its spread into bits everywhere. However failing that, leave them unplugged (unpowered) and in 70°C plus heat, the bits will lose their electrons rapidly.
I have been trying to understand what it is that makes it impossible to reliably wipe an SSD, compared to an HDD. Why wouldn’t filling the drive with 0s work?
But if I fill a drive with nonsense data, whether SSD or HDD, shouldn’t it be forced to write such data to all possible locations, thus overwriting the original data? Is am I misunderstanding something more fundamental about how this type of storage works?
@Logical Filling an SSD with zeros only affects the logical address space visible to your OS—it doesn’t force the controller to erase every physical block. The old data remains in unmapped or retired areas until (or unless) the controller decides to erase it later, potentially allowing recovery with specialized tools. Some SSDs might even optimize by not physically writing zeros if they detect a full block of them, simply marking the space as erased without touching the hardware.
See what I’m still not getting though, is how there can still be unmapped or retired areas, if the drive has been filled with (meaningless) data? Let’s say it isn’t all zeros, but random data instead. Are there more physical blocks than is represented logically by the adress space exposed to the OS?
On big flash memory you typically have more memory on the chips, than ia presented to the OS. Flash has significantly less write cycles, before the block breaks, so the controller monitors the health and won’t use it anymore when it will soon fail. Instead it uses a block from its unused extra space. (Details might be different, I’m not sure about that). This way the lifetime of the SSD is significantly improved. SD cards do the same, I think.
So the data in the retired blocks will remain and cannot be overwritten by the OS. If they are encrypted and the keys deleted, that won’t matter
One has to find the right balance between security and comfort, and this entirely depends on the threat model one has. Nowadays, I will always enable full-disk encryption on all of my devices, even if I then decide to store the keys in TPM and unlock the disk at boot.
I have at least 5 half-broken HDDs sitting around, completely unencrypted, I have no idea if they still work, but they are surely full of private data that I would like to have purged. I fear mechanical destruction might be the only solution for some of them, but just wiping them manually is more effort than doing nothing, so I guess they will still be around for some time. And with SSDs, there is no reliableway delete all data.
With encryption? Just delete the key and you are done.
The threat model changes in the future? Easy, the data is already encrypted.
I thought there was a table method of “destruction”. Like you delete or destroy the table of allocation. Even though the data is on the SSD, its not contiguous like HDD and so its spread into bits everywhere. However failing that, leave them unplugged (unpowered) and in 70°C plus heat, the bits will lose their electrons rapidly.
This is true. For now…
I have been trying to understand what it is that makes it impossible to reliably wipe an SSD, compared to an HDD. Why wouldn’t filling the drive with 0s work?
@Logical @shadowtofu
The SSD controller does not overwrite the old physical location (unlike HDD).
It writes the new data to a different physical block.
The old block becomes “stale” but still contains your original data until the SSD decides to erase it later.
But if I fill a drive with nonsense data, whether SSD or HDD, shouldn’t it be forced to write such data to all possible locations, thus overwriting the original data? Is am I misunderstanding something more fundamental about how this type of storage works?
@Logical Filling an SSD with zeros only affects the logical address space visible to your OS—it doesn’t force the controller to erase every physical block. The old data remains in unmapped or retired areas until (or unless) the controller decides to erase it later, potentially allowing recovery with specialized tools. Some SSDs might even optimize by not physically writing zeros if they detect a full block of them, simply marking the space as erased without touching the hardware.
See what I’m still not getting though, is how there can still be unmapped or retired areas, if the drive has been filled with (meaningless) data? Let’s say it isn’t all zeros, but random data instead. Are there more physical blocks than is represented logically by the adress space exposed to the OS?
On big flash memory you typically have more memory on the chips, than ia presented to the OS. Flash has significantly less write cycles, before the block breaks, so the controller monitors the health and won’t use it anymore when it will soon fail. Instead it uses a block from its unused extra space. (Details might be different, I’m not sure about that). This way the lifetime of the SSD is significantly improved. SD cards do the same, I think.
So the data in the retired blocks will remain and cannot be overwritten by the OS. If they are encrypted and the keys deleted, that won’t matter
Okay, that makes a lot more sense then. Thanks!