> > I think you can "remove" (well, not literally)
> > some of the not-so-random data in the inputs
> > for the random generator (like the 60Hz of the
> > current, processor harmonics, etc.) by first
> > sending the random-data trough a compressor.
> > bzip2 or gzip or whatsoever. By compressing
> > data, you'll remove redundancy from data which
> > should remove repeating events like the 60hz
> > stuff. See also the thread that spawned on this
> > mailinglist on that message I wrote about the
> > randomness of the kernel :-)
> Folkert, sorry for being a bit harsh,
That's ok.
> but I recommend that you refrain
> from posting stuff about cryptography until you know something about
> the subject.
> For "untrained" eyes, the data from gzip looks a lot more random than
> the input data. In reality it isn't. It's LESS random.
> If we take the (old and no longer often used) algorithm for
> "compress", then you'll see the first 256 bytes of an input file
> stored in at least 9 bits per byte. Because the byte-boundaries are no
> longer aligned, you no longer SEE that an "a" (0110.0001) is stored as
> 0.0110.0001, in fact, with 1/8th LESS entropy than the input data.
It was just an example. I think gzip/compress/whatever is not a good
example. Also; it is not necessary to store all data to be able to de-
compress things. One could skip some bits? Like; when you know that in
fact the entry would use like 8 bits (for the 8), just skip that 9th
bit.
-- ------------------------------------------------------------ Folkert van Heusden http://www.vanheusden.com/ some e-mail addresses: f.v.heusden@ftr.nl, flok99@dds.nl mobile phone: +31-6-22390057- 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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:26 EST