Date: Sun, 23 Jul 2000 12:10:06 +0200 From: Mark Murray <mark@grondar.za> To: Kris Kennaway <kris@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak Message-ID: <200007231010.MAA00467@grimreaper.grondar.za> In-Reply-To: <Pine.BSF.4.21.0007230042250.81127-100000@freefall.freebsd.org> ; from Kris Kennaway <kris@FreeBSD.org> "Sun, 23 Jul 2000 00:49:35 MST." References: <Pine.BSF.4.21.0007230042250.81127-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. Tradeoff. What do you want? Lightning fast? Excessive security? Balance it out. > > > 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 None, but very paranoid reseed intervals can be set if required. (Requires more entropy-harvesting, but doable). > > 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. The acknowlegment that I am looking for is that the old, simple "gather entropy, stir with hash, serve" model is inadequate IMO, and I have not seen any alternatives. > 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. Goes for any tool; a universal truth. I'm trying to come up with a better tool that what was, and I believe that I have, and I am perhaps misunderstanding folks' motives in shouting for the blocking model. In quite a few cases, it has been a very obvious non-understanding of what Yarrow is (I apologise for lumping you in this category). I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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?200007231010.MAA00467>