lkml.org 
[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: /dev/random in 2.4.6
    >> Am I correct in assuming that in the absence of other entropy sources, it
    >> would use these (potentially inferior) sources, and /dev/random would
    >> then not block? In which case fine, it solves my problem.
    >
    > No, /dev/random would always keep a conservative estimate of entropy.
    > Assuming that network entropy > 0, this would add more real (but
    > unaccounted) entropy to the pool, and if you agree with this assumption,
    > you would be able to take advantage of it by reading /dev/urandom.

    OK; well in which case it doesn't solve the problem. I assert there are
    configurations where using the network to generate accounted for entropy
    is no worse than the other available options. In that case, if my entropy
    pool is low, I want to wait long enough for it to fill up (i.e. have the
    /dev/random blocking behaviour) before reading my random number. If your
    interpretation of Ted's suggestion is correct, this is no better than
    switching to /dev/urandom, which is considerably worse than the effect
    of using Robert's patch. I thought what Ted was suggesting was only
    accounting for network-IRQ derived entropy when the entropy pool was
    mostly empty. This would mean that if there were other sources of entropy
    about, the network entropy would not be accounted for (which sounds
    reasonable, on the presumption that they were better quality).

    An alternative approach to all of this, perhaps, would be to use extremely
    finely grained timers (if they exist), in which case more bits of entropy
    could perhaps be derived per sample, and perhaps sample them on
    more operations. I don't know what the finest resolution timer we have
    is, but I'd have thought people would be happier using ANY existing
    mechanism (including network IRQs) if the timer resolution was (say)
    1 nanosecond.

    --
    Alex Bligh
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:57    [W:0.024 / U:0.172 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site