On Tue, 2019-01-29 at 16:20 -0800, Gordon Messmer wrote:
On 1/28/19 2:12 AM, Patrick O'Callaghan wrote:
Another point: several people have mentioned using /dev/urandom. It's important to note that this is a *pseudo-random* generator. It starts from a random seed, but from that generates a completely deterministic pattern. If you have the seed, you have everything. ...
I think that you are confusing two separate concerns. This thread (as confused and meandering as it is) is concerned with clearing the content of a disk. That is completely unrelated to the concerns about generating secure encryption keys, which appears to be what you're alluding to when you raise concerns about predicting the output of the CSPRNG (cryptographically secure pseudorandom number generator).
I'm actually not confused, I merely made some remarks about PRNGs, though I admit to not knowing that /dev/urandom did occasionally top up its randomness. I guess trying to chip in something in the middle of confusion creates more confusion ...
Even if you could predict the entire sequence of the CSPRNG (which, to be clear, you can't; Linux continues to feed entropy into the state of the CSPRNG used for /dev/urandom) that wouldn't make writing /dev/urandom to the disk any less secure. Either way, the random data will replace the old data, and the drive itself will never read out the data that has been overwritten. As far as reading data from the drive itself is concerned, writing /dev/zero to the disk is the fastest way to clear a disk, and totally effective.
The question of secure erase is largely academic. If you are a military or intelligence organization and the content of a disk might threaten the lives of people in your organization, then you should do something better than writing zeros to your disk. You face one of several problems including:
1: If you have very old spinning magnetic drives, an attacker might be able to use a Spin Polarized Scanning Tunneling Microscope to read residual data after a disk was zeroed.
2: Either HDD or SDD disks might mark a block bad and remap it. Such a block could in theory still be read by a modified controller (or if an attacker could clear the remapping data).
If you are concerned about a well-funded attacker reading your data, then the preferred solution is one or both of:
1: physically destroy the disk
2: always encrypt your disks from the start and never write unencrypted data
In general, though, this thread has entirely too much speculation and is becoming quite detached from reality.
Agreed.
For further reading on SSDs, this paper may be interesting:
https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf
This AMA with a data recovery engineer might be, too.
https://www.reddit.com/r/IAmA/comments/2n02lt/iama_data_recovery_engineer_i_...
Good references, thanks.
poc