point...
> > Also, I would probably use a
> > cryptographic hash function instead...
>
> I understood that a cryptographically strong hash wasn't needed here. You
> are just trying to overwrite the data to be wiped with (pseudo)random bytes
> to make recovery more difficult, and the objection to using /dev/urandom
> (cryptographically strong hash) was that it is too slow. I don't know
> anything about the technology to be used for this "recovery", but what was
> discussed here was using an electron microscope to read off the previous
> contents of the platter bit by bit. Sounds horribly expensive to me, if
> your data is important enough to warrant protection against _that_ kind of
> reading, you'll be more than willing to sandblast the magnetic covering off
> the disk and melt the whole down afterwards.
>
> If your objection stands, you could reseed the sequence each, say, 200
> iterations, and just use the high byte each time.
Actually, I think it turns out that knowing the sequence of "random"
values that were written can make reading the overwritten data easier.
If this is indeed the case, you want something mildly more secure...
Here's an idea for what I think will be a relatively secure PRNG (but
I'm not a cryptographer): Take 2 values generated in a secure manner,
storing one of them in memory. Perform a cryptographic hash over these
two values; use the results as your first random value. When you need
another random value, perform another cryptographic hash over the first
value, which you saved, and the last generated value.
Properties I see here:
* Because you're using cryptographic hashes, you cannot easily recover
a previous value in the sequence given a later value.
* Because you're performing the hashes with an unknown value in
addition to previous values of the sequence, it is difficult to
predict later values in the sequence.
Of course, this relies on the security of the hash you choose, and the
source of your initial random values also needs to be very secure;
knowledge of the seed would still give away the whole sequence.
--
Kevin L. Mitchell <klmitch@mit.edu>
------------------------- -. .---- --.. ..- -..- --------------------------
http://web.mit.edu/klmitch/www/ (PGP keys availiable from here)
RSA AE87D37D/1024: DE EA 1E 99 3F 2B F9 23 A0 D8 05 E0 6F BA B9 D2
DSS ED0DB34E/1024: D9BF 0E74 FDCB 43F5 C597 878F 9455 EC24 ED0D B34E
DH 2A2C31D4/2048: 1A77 4BA5 9E32 14AE 87DA 9FEC 7106 FC62 2A2C 31D4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/