[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: /dev/random in 2.4.6
    Alex Bligh - linux-kernel wrote:
    > 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.

    I'm probably wording this poorly, but I'm going to call a device that
    provides irqs, and which is probably not predictable except under a
    severe attack, a pseudo-entropy source, and other devices which are
    presumed to be non-observable or otherwise unpredictable an entropy
    source. Examples, eth0 or a modem as pseudo-entropy source, and hard
    drive, keyboard, or mouse activity as entropy source (although if you
    use wireless keyboard or mouse, more likely they'd have to be
    reclassified as pseudo-entropy sources).

    Why is it required to use only the time between irq's of a single device
    for start/stop times (time delta measurement)? If the time period were
    instead calculated not on the time between irq of a single device, but
    instead start and stop times were based on different device irq's, then
    many pseudo entropy sources could become full entropy
    accurately/precisely snoop eth0 traffic and determine it's irq would no
    longer be helpful if the time involved the starting of a timer from
    eth0, but the stop (and thus delta) was derived from something else like
    hard drive activity. Force the attacker to monitor more than one irq,
    plus require the attacker to know which irq device corresponds to the
    stop irq of a particular timer.

    A variation on the theme would be to rotate which entropy source is used
    as the stop event whenever a pseudo entropy source starts a timer. E.G.,
    eth0 irq starts a timer, and the hard drive is set to stop the timer on
    eth0 (the same hard drive timer could also start or stop a hard drive
    time delta, it's a separate issue) the first time, but using this irq
    causes eth0 stop events to now be bound to mouse events instead. In that
    example, the attacker would have to monitor both eth0 irq, and hard
    drive irq, as well as knowing that the hard drive is the stop event; the
    first time it is used, the attacker would then have to be able to
    monitor the eth0 irq, and the mouse irq, along with knowledge that the
    mouse irq is now the stop event (and the first time a mouse event is
    used as a stop event to the eth0 timer, a new stop event device would be
    rotated in). Given a mouseless/keyboardless/headless machine, but with
    several pseudo entropy sources, one could still have some degree of
    confidence even when the attacker controls and monitors all pseudo
    entropy source irq's, based on the notion that the attacker won't know
    *which* irq corresponds to a start or stop event (knowing irq no longer
    provides a direct time measurement). If pseudo entropy sources used
    trusted entropy sources for stop events, this would be preferable, but a
    completely pseudo entropy set of sources could become much more trusted
    if the exact rotation scheme in use at each irq was not known to the
    attacker. Would it be practical to segregate begin/end irq timer events
    to different devices, rather than having begin/end events based soley on
    a single device?

    D. Stimits,

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