[lkml]   [2001]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] random.c bugfix
    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

    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.

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

    Cheers, Andreas
    Andreas Dilger

    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:18    [W:0.024 / U:57.712 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site