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).
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.
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_get_files_from/
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
