4 ms·
> When the authors tested a drive that existed at the time Gutmann wrote that paper in optimal conditions there was only a 92% chance of recovering a bit correc
by yellowapple 4y ago
> When the authors tested a drive that existed at the time Gutmann wrote that paper in optimal conditions there was only a 92% chance of recovering a bit correctly. The chance to successfully recover exponentially decays with the number of bits you want to recover.
That's still a non-zero probability. For folks whose tolerance for data exfiltration is "zero", anything non-zero, no matter how infinitesimally small, is non-acceptable - hence: physical destruction rather than relying on overwriting.
Thankfully, as mentioned previously, said folks are a pretty tiny minority of the total hard drive market, and are typically the folks encrypting everything at rest anyway. A random pass or two over encrypted data is more than enough to ensure that even if an attacker is able to accurately recover old bits, there's no telling whether or not those old bits are actually data.
> We were talking about HDDs. SSDs are out of scope.
If we're going to adjust our expectations for "overwriting is sufficient for data destruction" based on changes in technology, then SSDs are absolutely in scope - and indeed have their own set of implications when it comes to data retention after overwrite (like TRIM, as mentioned before, or the general case of two writes to the "same" block not necessarily being written to the exact same set of cells).
- charcircuit 4y ago>That's still a non-zero probability Just as there is a nonzero chance of someone recovering your data by reading /dev/urandom. Technically your data could be outputed but the person reading /dev/urandom would not be able to tell if it was just random data or if it was what was wiped. Even if your tolerance for data exfiltration is 0 you can be okay with a non 0 chance for someone to randomly generate the data. >If we're going to adjust our expectations for "overwriting is sufficient for data destruction" based on changes in technology, then SSDs are absolutely in scope The process of wiping SSDs is different because you don't do it by overwriting all of the data, but instead by initiating a secure erase.
- yellowapple 4y ago> Just as there is a nonzero chance of someone recovering your data by reading /dev/urandom. That variety of non-zero is much closer to zero than the risk of increasingly-sophisticated equipment being able to recover overwritten data - and unlike the non-zero risk of such an "infinite typewriters" sort of attack, mitigating the non-zero risk of recovering overwritten information from media is straightforward: destroy the media. > The process of wiping SSDs is different because you don't do it by overwriting all of the data, but instead by initiating a secure erase. In other words: trusting an opaque blob of SSD firmware to overwrite all of the data for you.
- charcircuit 4y ago>zero than the risk of increasingly-sophisticated equipment being able to recover overwritten data No, it isn't. Reread the paper I referenced. The chance of recover exponentially decays which means the probability does quickly go to zero as the number of bits you want to recover increases. >trusting an opaque blob of SSD firmware to overwrite all of the data for you. No, you are trusting them to overwrite the encryption key and that the encryption being used is secure.
- yellowapple 4y ago> Reread the paper I referenced. I did. > The chance of recover exponentially decays As does the chance of a random number generator accidentally recreating your secret. And that's assuming, again, that technology doesn't improve. > No, you are trusting them to overwrite the encryption key and that the encryption being used is secure. 1. That's hardly any more reassuring (though at least it does hopefully mitigate overwriting concerns, assuming that key can't be recovered and the encryption method is indeed more secure) 2. That doesn't explain why secure erase commands take so long relative to other ATA commands (anywhere from seconds to hours), or why that time scales with drive size.