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>