[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.082 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site