lkml.org 
[lkml]   [2001]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][RFC] Allow net devices to contribute to /dev/random
    Hi,
    I would actually suggest breaking out a longer discussion of the
    risks associated with the patch into Documentation, and _strongly_
    suggesting that the person configuring the kernel read it before
    enabling the option. Then a statement that this may put the security
    of /dev/random at risk would probably be enough.

    So let's start with the possible conditions are.
    What I can see are the following:
    1) network card on visible net:
    - BadGuy can monitor the network traffic, extracting
    timing information. Given enough knowledge about the
    latency of the network card, all network entropy might
    be known (making it non-secure). If the network is
    the only, or primary, source of entropy this leads
    to compromise
    2) network card on private net:
    - BadGuy must plug into private net to monitor the traffic,
    any external monitoring is very likely to fail to get
    much useful information.
    3) TSC not used to add randomness:
    - Prediction of time between interrupts becomes much easier
    (jiffies are a big target).
    4) Systems that are largely quiescent could lead to easier prediction
    of latencies, and thus easier compromise.

    In any case the following must be true for this to cause problems:
    a) The network must be the primary source of entropy (this
    will be common in the case where the patch is useful)
    b) BadGuy must monitor from time 0 (boot of system) to get
    useful information
    c) BadGuy must have information about what network card the system
    has, or _very_ good statistical information about delay to
    interrupt & timing in general.
    d) BadGuy must have information about how long the processing for
    the interrupt handler takes, as the randomness addition is done
    _after_ all processing. This also causes interesting problems
    for prediction if more than one event is handled at once.
    e) BadGuy must have access to information of network traffic on
    all the networks that are attached to the computer.

    Now none of this guarantees security (but then again, very little will
    _guarantee_ security.

    I may have missed some stuff here... (caveat emptor)

    Just as a comment, I actually like the patch, and would certainly be
    willing to use it for a computer on a private network...
    -gordo
    -
    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:5.134 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site