Date: Sun, 23 Jul 2000 00:49:35 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak Message-ID: <Pine.BSF.4.21.0007230042250.81127-100000@freefall.freebsd.org> In-Reply-To: <200007230739.JAA94403@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jul 2000, Mark Murray wrote:
> > Okay, using RSA keys wasn't the best example to pick, but Yarrow also
> > seems easy to misuse in other cases: for example if you want to generate
> > multiple 256-bit symmetric keys (or other random data) at the same time,
> > each additional key after the first won't contain any additional entropy,
> > so if you break the state of the PRNG at the time the first one was
> > generated you get the others for free (until the thing reseeds).
> >
> > This design tradeoff is discussed in section 4.1 of the paper.
>
> Tweakable.
Doing a reseed operation with every output is going to be *very*
computationally expensive.
> > > That said, there is nothing to prevent the system admin
> > > from tweaking the Yarrow security parameters so that
> > > Yarrow will only spit out as many bits or pseudo-randomness
> > > as it gathers bits of entropy.[4]
> >
> > Well, I don't see a way to tune this without modifying the Yarrow design,
> > since the entropy pool is intentionally decoupled from the output
> > mechanism, and it seems like it would add additional (unnecessary)
> > overhead anyway to use it in that fashion.
>
> Look at the sysctls (some improvements and documentation coming).
Please tell me which of the following sysctls will cause Yarrow to
deactivate the keyed cipher feature that spits out a constant data stream
independent of the state of the entropy pools:
kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 100
kern.random.yarrow.slowthresh: 160
kern.random.yarrow.slowoverthresh: 2
> > Indications are we can probably get quite a lot of usable entropy from a
> > standard system (on the order of many kilobytes per second - but I need to
> > read more of the literature about processing of entropy samples) - in this
> > case I think maintaining a third pool which is directly tapped by
> > /dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to
> > go.
>
> I suspect you are missing the whole point of yarrow. Yarrow protects
> you from the compromises inherent in attackers injecting their own
> junk into the "third pool".
Mark, I understand this stuff quite well - I'm not "missing the whole
point of Yarrow" at all. Yarrow is a good system as far as it goes, but
the authors themselves admit this limitation - you just can't use this
tool in contexts it was not designed for.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007230042250.81127-100000>