Messages in this thread | | | Date | Mon, 29 Oct 2001 16:39:20 -0700 | From | Andreas Dilger <> | Subject | Re: [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 errors.
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 http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
- 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/
| |