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,
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
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.
Good references, thanks.