On Mon, 2019-01-28 at 14:03 +0000, Ian Malone 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. And since the idea > > here is to overwrite the disk, the first part of which contains > > "plaintext" that follows a regular layout (partition table etc.) it > > makes the task of decoding the disk even easier as that's the only part > > you would actually have to analyse at a physical level. > > > > /dev/urandom isn't purely pseudorandom, it does use entropy from the > pool, it will become pseudorandom when entropy runs out and become > random again when more entropy arrives. Good to know. > Unless you have a hardware > entropy source I suspect using /dev/random will take a much longer > time to produce enough data even for a single over-write. Of course. > However it's > worth noting that the over-write process is not simply XOR with the > written bytes (in which case enough plaintext to work out the sequence > would definitely let you recover the rest of the data), it's > attempting to randomise the hysteresis effect on the media, which is > why multiple writes are good, because though they theoretically just > increase the number of possible residual states each time you do it > the residual size of the signal you're over-writing is reduced, and > attempting to get the sequences applied to a known plaintext will > become harder. I assume you mean 'shred' does this. 'dd if=/dev/urandom ...' won't. > I wouldn't recommend just doing /dev/zero if the CIA, > or even a moderately funded newspaper might specifically be after your > data, but it would certainly be enough to stop a casual user plugging > it in and getting anything back, a few urandom writes is enough to > stop anyone without serious cryptographic expertise and access to the > equipment necessary to read the platters directly getting anything off > the disc. Indeed. 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
