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