[lkml]   [2001]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: /dev/random in 2.4.6
    On Tue, 21 Aug 2001, Alex Bligh - linux-kernel wrote:

    > > No you don't, that's your whole complaint to start with. You're clearly
    > > entropy-limited. If you were willing to block waiting for enough entropy,
    > > you'd be fine with the current scheme.
    > Yes I /do/. I want to wait for sufficient entropy. I count inter-IRQ
    > timing from network as a source of entropy. IE if the entropy pool
    > is exhausted, I'm prepared to, and desire to, block, until a few packets
    > have arrived. However, I do not wish to block indefinitely (actually
    > about 3 minutes as there's a little periodic block I/O) which is what
    > happens if I do not count network IRQ timing as an entropy source
    > (current /dev/random result, without Robert's patch, on most NICs).
    > Equally, I do not want want to read /dev/urandom (and not block)
    > which, in an absence of entropy, is (arguably) cryptographically weaker
    > (see below).

    You're throwing the baby out with the bathwater. If you overestimate the
    entropy added by even a small amount, /dev/random is no better than

    Imagine your attacker has broken into your firewall and can observe all
    packets on your network at high accuracy. She's also got an exact
    duplicate of your operational setup, software, hardware, switches,
    routers, so she's got a pretty good idea of what your interrupt latency
    looks like, etc., and she can even try to simulate the loads you're
    experiencing by replaying packets. She's also a brilliant statistician. So
    on each network interrupt, when you're adding, say, 8 bits of entropy to
    the count, she's able to reliably guess 1. Really she only needs to guess
    one bit right more than half the time - so long as she can gather slightly
    more information than we think she can. Since your app is occassionally
    blocking waiting for entropy, you're giving it out faster than you're
    taking it in. Assuming your attacker has broken the hash function (SHA and
    then some), it's just a short matter of time before she has enough
    information to correlate her guesses and what you've sent to figure out
    exactly what's in the pool and start guessing your session keys. Assuming
    she hasn't broken SHA, then /dev/urandom is just as good.

    So the whole point of /dev/random is to be more secure than just the hash
    function and mixing. Which do you think is easier, breaking the hash
    function or breaking into your network operations center and walking off
    with your server? If your NOC is so secure, then you can probably afford a
    hardware entropy source..

    Read Schneier's essay on attack trees if the above argument doesn't make
    sense to you:

    > Measuring it there at least 16 network IRQs for the minimum
    > SSL transaction. That generates 16x12 = 192 bits of
    > entropy (each IRQ contributes 12 bits).

    12 bits is a maximum and it's based on the apparent randomness of the
    interrupt timing deltas. If your attacker is impatient, she can just ping
    you at pseudo-random intervals tuned to clean your pool more rapidly.
    You're also forgetting that TCP initial sequence numbers come from the
    pool to prevent connection spoofing - more entropy lost.

    > The point is simple: We say to authors of cryptographic applications
    > (ssl, ssh etc.) that they should use /dev/random, because /dev/urandom
    > is not cryptographically strong enough.

    Who ever said that? /dev/random is a cute exercise in paranoia, not
    practicality. It's nice for seeding personal GPG keys and ssh identities,
    but was never intended for bulk cryptography. It's also nice for keys
    you're going to reuse because if your attacker monitors all your traffic
    and holds onto it for 50 years, and SHA happens to gets broken before El
    Gamal, your GPG key is still safe.

    "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

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