From: Andreas Dilger <adilger@turbolabs.com>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Horst von Brand <vonbrand@inf.utfsm.cl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random.c bugfix
Date: Mon, 29 Oct 2001 16:39:20 -0700 [thread overview]
Message-ID: <20011029163920.F806@lynx.no> (raw)
In-Reply-To: <200110291615.f9TGFYYY010564@pincoya.inf.utfsm.cl> <Pine.LNX.4.30.0110291053240.5815-100000@waste.org>
In-Reply-To: <Pine.LNX.4.30.0110291053240.5815-100000@waste.org>; from oxymoron@waste.org on Mon, Oct 29, 2001 at 10:58:28AM -0600
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/
next prev parent reply other threads:[~2001-10-29 23:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-27 4:21 [PATCH] random.c bugfix René Scharfe
2001-10-27 6:21 ` Andreas Dilger
2001-10-27 6:35 ` Robert Love
2001-10-28 23:57 ` Horst von Brand
2001-10-29 5:37 ` Andreas Dilger
2001-10-29 16:15 ` Horst von Brand
2001-10-29 16:58 ` Oliver Xymoron
2001-10-29 23:39 ` Andreas Dilger [this message]
2001-10-30 0:23 ` Oliver Xymoron
2001-10-30 3:50 ` Andreas Dilger
2001-10-30 16:07 ` Theodore Tso
2001-10-31 6:19 ` Andreas Dilger
2001-10-31 14:42 ` Oliver Xymoron
2001-10-30 4:49 ` Andreas Dilger
2001-10-29 5:46 ` [PATCH] MAJOR " Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011029163920.F806@lynx.no \
--to=adilger@turbolabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oxymoron@waste.org \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox