[lkml]   [1997]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: monitoring entropy
>> It's just that there is a (very hard to compute)
>> correlation between previously read data and subsequent results.

> frequently, such 'unpredictibility proofs' is just based on _one_
> measurement. But here we can basically 'sample' the pool virtually
> _infinit times_. I cant prove it right now, but i _bet_ if i freeze the
> entropy pool and read /dev/urandom, i will get constant/periodic output,
> isnt it so?

Well, it depends on what you mean by "freeze the pool". If you mean
somehow make all writes to the memory silently fail, then you're right,
you'll get constant output from /dev/random. But every time you read
from /dev/random, it adds the current time to the pool, hashes the pool
to produce some output, adds the outpuyt back into the pool, and
returns half of the hash output. (Repeat as often as necessary to fill the
number of bytes requested in the read.) Thus, reading alters the pool.
The expected cycle length is something on the order of 2^2048, so
the "periodic" part isn't a big concern.

> 'freezing' the pool, or polling it much faster than events get added to
> the pool is the same thing ...

Not at all. First of all, notice what I said... just reading the pool is
completely *harmless* unless you *do* something with the data that is read.
You can read all you like from /dev/urandom and it won't make it any more
likely that it will start returning all zeros or some such.
All that someone can do is gather information to help them predict the
future output, i.e. to guess what it's going to be. You have to read
/dev/urandom and then put in a lot of hard thinking.

 \ /
  Last update: 2005-03-22 13:40    [W:0.044 / U:4.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site