On Mon, 28 Jan 2019 at 15:43, Patrick O'Callaghan <pocallag...@gmail.com> 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@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to