lkml.org 
[lkml]   [2002]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Problem with random.c and PPC
    On Mon, Aug 19, 2002 at 11:29:00AM +0200, Marco Colombo wrote:
    > On Sat, 17 Aug 2002, Oliver Xymoron wrote:
    >
    > > > If you are in there fixing things, it might make sense to have
    > > > /dev/urandom extract entropy from the random pool far less often than
    > > > /dev/random. This way people who use /dev/urandom for a source of
    > > > less-strong randomness (e.g. TCP sequence numbers or whatever), will
    > > > not be shooting themselves in the foot for when they need a 2048-byte
    > > > PGP key, if they are low on entropy sources.
    > >
    > > Not sure this is an ideal fix. We might instead have an entropy
    > > low-water mark (say 1/2 pool size), below which /dev/urandom will not
    > > deplete the pool. This way when we have ample entropy, both devices
    > > will behave like TRNGs, with /dev/urandom falling back to PRNG when a
    > > shortage is threatened.
    >
    > How can you make /dev/urandom return something without leaking
    > information about the internal pool state to the observer?
    > Do you plan to switch to a completely different source and reseed the
    > PRNG with data not taken from the pool?

    I plan to make a third pool, reseeding from the first. The code
    appears to actually be structured with that in mind, it just hasn't
    been done.

    > In my experience, there's little you can do when the entropy demand is
    > higher than the rate at which the kernel collects it. Either we implement
    > /dev/random quotas, or it will be always easy to drain the internal pool
    > from userspace.

    Root can decide, for instance, to make /dev/random privileged to some
    group if important_set is getting starved by unimportant_set.

    > I'd say that /dev/urandom interface is somewhat broken: the application
    > either can live with an almost pure PRNG (and use an userspace
    > implementation) or needs true, pure and strong randomness. The programmer
    > should know the mimimal need for true randomness of the application.
    > For every application that uses /dev/urandom, it's 0 by definition of
    > /dev/urandom, and the application should just use an userspace PRNG.

    Many actually do this. I believe OpenSSL merely seeds though I'd have
    to doublecheck.

    > If you need a weak solution (a perturbated PRNG), just read a few bits
    > from /dev/random at times (but in a controlled and defined way).

    It might be helpful to think of /dev/urandom as akin to /dev/random with
    O_NONBLOCK. "Give me stronger bits if you got 'em" is desirable,
    otherwise this thread would be much shorter.

    --
    "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 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:28    [W:0.027 / U:64.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site