[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.019 / U:17.464 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site