[lkml]   [2001]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] let Net Devices feed Entropy, updated (1/2)

    (off list - as I've posted this elsewhere)

    >> This is not the issue; some of use _are_ worried whether or not we
    >> have enough entropy (and want a read that blocks until sufficient
    > If you are that worried, shouldn't you be using a hardware generator?

    You could say the same thing to anyone who uses /dev/random
    rather than /dev/urandom. Why use /dev/random when it can
    block (inconvenient) instead of a h/w random number generator?

    I'm sufficiently concerned that I want to have some 'external'
    entropy, and on the machine in which it is causing me problems,
    in an idle state, there is no other entropy source, but lots of
    network activity which I trust can't be snooped on.

    The machine was bought and tested in one config. A hardware
    random number generator is something else to go wrong, and
    additional expense.

    Using an entropy estimate which includes network event timings
    is no[1] worse (in this situation) than using (say) IDE interrupt
    timings. And no better. It certainly isn't as good as using
    an external random number generator. However, it is better
    than using /dev/urandom and leaving the kernel unpatched
    (see previous analysis). It's a trade-off. But if we can make
    (depending on circumstance) the OS (s/w) perform better
    with given h/w, that sounds like a good thing to do to me.

    [1]=certainly not a lot worse.

    Alex Bligh
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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