On Mon, 28 Jan 2019 at 15:43, Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > > On Mon, 2019-01-28 at 14:03 +0000, Ian Malone wrote: > > > > /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. > Yes, default is 3 writes. But since I'm checking, it's been a while since I read the shred manpage... It turns out the default source is actually not discussed, so may be a purely pseudorandom algorithm, rather than /dev/urandom. It's after midnight here, so I'm not inclined to dig into the source right now to find out. It is possible to specify urandom if wished by using the --random-source argument. One old piece of advice that may be outdated now, multiple writes are a good idea, because the residual signal on magnetic media is less than the current value, my understanding is that at one point you could effectively substract out the ideal current signal to retrieve the last value, which would work even against a random overwrite. Of course disc technology has moved on a lot and technologies like shingling may have turned that into an extra data channel by now. The truely paranoid might still want to use a physical shredder rather than a software one. -- imalone http://ibmalone.blogspot.co.uk _______________________________________________ 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
