[lkml]   [2001]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] random.c bugfix
    On Mon, 29 Oct 2001, Andreas Dilger wrote:

    > On Oct 29, 2001 10:58 -0600, Oliver Xymoron wrote:
    > > > > (*) I don't know enough about the hash functions to know how to add a
    > > > > few odd bytes into the store in a useful and safe way. We don't
    > > > > really want to discard them either - think if a user-space random
    > > > > daemon on an otherwise entropy-free system only writes one byte at
    > > > > a time...
    > > >
    > > > I'm no expert either, but padding with anything (zeroes?) to get the right
    > > > length should be safe, no?
    > >
    > > No. A 4-byte accumulator is the right answer. We have to be careful here
    > > though - the actual entropy might be in the partial words, we have to
    > > account for it conservatively.
    > In a large majority of the cases, there are only full-word entropy additions.
    > The only time we need to deal with sub-word additions is from random_write()
    > and from the equivalent ioctl. It also appears that we do this when filling
    > the secondary pool, but that is OK because we periodically dump far more
    > entropy into the secondary pool than we could possibly lose through rounding
    > errors.

    They're not rounding errors per se though. This is what I mean by
    conservative accounting. If you have three extra bytes, you must assume
    that they're worth a full 24 bits of entropy. Throwing them away is fairly

    > Having an accumulator would only handle a rarely-used corner case. We
    > could just as easily fix any user-space entropy daemon to write at least
    > 4 bytes at a time. Alternately, we could "pad" with enough bytes from
    > the random pool, and not accumulate at all.

    Padding -from the pool- is acceptable (and simple enough a slow path to
    add to the low-level function). Padding with constants is bad and padding
    with zeros tends to be really bad.

    > In any case, this is in the noise compared to not using the input data
    > at all (which I fixed in the other patch).

    Any of this made it into recent kernels yet? Backport to 2.2 might be a
    good idea too..

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