lkml.org 
[lkml]   [2001]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH][RFC] Allow net devices to contribute to /dev/random
    From
    Date
    On Tue, 2001-09-25 at 20:20, David Wagner wrote:
    > I'm worried about the language in the configuration documentation:
    > + Some people, however, feel that network devices should not contribute to
    > + /dev/random because an external attacker could observe incoming packets
    > + in an attempt to learn the entropy pool's state. Note this is completely
    > + theoretical.
    > Incrementing the entropy counter based on externally observable
    > values is dangerous. Calling this risk 'completely theoretical'
    > is, I believe, a misrepresentation, unless I've missed something.

    First, I agree the wording is too `kind' and I will change it.

    However, the actual end result -- that the output of /dev/random can be
    predicted -- is theoretical, because of the fact the output is one-way
    hashed. I do not want to get into another full discussion of this, but
    a thread exists about a month back that discussed it.

    To summarize: the patch is a risk if and only if: SHA-1 is cracked, an
    attacker can observe the state of network packets, and it contributes
    enough to the pool that enough of its state is learned.

    Some diskless machines really have _zero_ entropy. This patch does them
    good. If you don't want net devices to contribute, don't enable them.

    Hell, without this patch, some network devices do contribute! It
    actually standardizes the whole thing.

    > A failed RNG is one of the most likely -- and most devastating
    > -- failure modes possible for modern cryptosystems, and as such
    > it pays to be careful here. Are you proposing this for inclusion
    > in the mainline Linux kernel? If so, I'm concerned that this patch
    > could put security at risk. What am I missing?

    I would like to see it in the kernel, for 2.5.

    I agree a poor RNG is a risk. I also put forth that this patch is
    configurable and that WITHOUT it you actually have a few NIC drivers
    that contribute to /dev/random!

    If you are on a diskless system and need some seed for whatever, say SSH
    or just something dinky, this patch may be a requirement. Even on my
    workstation, sometimes SSH blocks for some seconds waiting for
    /dev/random to fill up.

    > Here is my reasoning. I'd like to quote drivers/char/random.c:
    > * add_interrupt_randomness() uses the inter-interrupt timing as random
    > * inputs to the entropy pool. Note that not all interrupts are good
    > * sources of randomness! For example, the timer interrupts is not a
    > * good choice, because the periodicity of the interrupts is too
    > * regular, and hence predictable to an attacker. Disk interrupts are
    > * a better measure, since the timing of the disk interrupts are more
    > * unpredictable.
    > *
    > * All of these routines try to estimate how many bits of randomness a
    > * particular randomness source. They do this by keeping track of the
    > * first and second order deltas of the event timings.

    Obviously the timer interrupt would be the worst idea ever. Its the
    same value (HZ) on almost all versions of Linux (Alpha being on example
    where it is not the same).

    > This suggests that add_interrupt_randomness() should not be called
    > on all interrupts without discrimination. Would it be fair to say
    > that your patch enables randomness collection on almost all interrupts?
    > If so, why is this safe to do?

    No, it enables them on the interrupt for your NIC, if you enable the
    config setting. If you don't enable the config, then your NIC won't
    contribute.

    If you don't use the patch, then it is unknown what your NIC will do
    without looking at the source. A few drivers currently do set
    SA_SAMPLE_RANDOM.

    > I hope you agree that making this configurable does not obviate our
    > responsibility to make sure that the default configuration is reasonable.

    The default is off.

    > This stuff is subtle, and changing it is not something I'd recommend
    > without a careful analysis of the impact on security. Moreover, the
    > comments about 'completely theoretical' leave me concerned that any
    > analysis that has been done on this patch may be based on misconceptions
    > about cryptographic security. Can you tell us anything about what
    > security analysis you've done so far?

    This patch has been around, and a consensus has been reached. I also
    understand the mathematics here.

    Again:
    Yes, network traffic can be observed (or even influenced) and this could
    allow an attacker to learn something of the state of your entropy pool.
    Note this would be hard due to clock skews and the such, but yes it is
    entirely possible.

    Yes, if your pool has little other entropy, the attacker now knows of a
    good deal of the state of the pool.

    Yes, assuming SHA-1 is at risk, the attacker can know for SURE the
    output of /dev/random.

    Yes, this is completely theoretical. Is this a risk? Sure. But it
    defaults to off. Sitting on my home network and knowing the strength of
    SHA-1, I don't fear any of this. Or maybe I am desperate for entropy
    since I have no disks or user interaction on this system. The patch was
    written out of a discussion for it, even.

    Thus, the patch defaults to off. By all means, keep it off. I agree
    the wording should be made more intimidating. However, without this
    patch, your NIC could be contributing -- the patch actually institutes a
    policy.

    That is all this is. Having a clearly defined policy, and letting it be
    configurable.

    --
    Robert M. Love
    rml at ufl.edu
    rml at tech9.net

    -
    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 13:03    [W:0.029 / U:0.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site