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_get_files_from/ Good references, thanks. poc _______________________________________________ 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
