From owner-freebsd-current Sun Jul 23 3:43:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id EC96C37BAB6; Sun, 23 Jul 2000 03:42:54 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id MAA00467; Sun, 23 Jul 2000 12:10:06 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007231010.MAA00467@grimreaper.grondar.za> To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak References: In-Reply-To: ; from Kris Kennaway "Sun, 23 Jul 2000 00:49:35 MST." Date: Sun, 23 Jul 2000 12:10:06 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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