From owner-freebsd-current Sun Jul 23 0:49:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 39E1037B96F; Sun, 23 Jul 2000 00:49:36 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id AAA83155; Sun, 23 Jul 2000 00:49:36 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Jul 2000 00:49:35 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: "Jeroen C. van Gelderen" , current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak In-Reply-To: <200007230739.JAA94403@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message