Date: Mon, 12 Apr 2004 08:07:43 -0400 From: Richard Coleman <richardcoleman@mindspring.com> To: David Malone <dwmalone@maths.tcd.ie> Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/modules/random Makefile src/sys/dev/random randomdev.h randomdev_soft.c randomdev_soft.h yar Message-ID: <407A868F.8040108@mindspring.com> In-Reply-To: <20040412113635.GA38733@walton.maths.tcd.ie> References: <20040410155637.Q58852@root.org> <200404110746.i3B7kiIn075106@grimreaper.grondar.org> <20040412113635.GA38733@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
David Malone wrote: > On Sun, Apr 11, 2004 at 08:46:43AM +0100, Mark Murray wrote: > >>Yarrow is unsuitable for this purpose; it is a great generator when >>you have a low-entropy environment and you need to protect against >>attackers having potential knowledge of the inputs. > > > I still think it would be nice if our random infrastructure had a > block-until-accumulated-'enough'-randomness mode, like the old > /dev/random had, to avoid some future attack based on Yarrow's fixed > size state. I don't think it will be a realistic attack any time > soon, but it might be nice for baco-hat types. In the case where > high-quality, fast hardware based generators are available, this > seems to be a more realistic option though. > > I'm happy enough to live without this, since we thrashed this out > before, but if you're looking at options, you might keep it at the > back of your mind. > > David. I think the old /dev/random caused more problems than it solved. Most apps just used /dev/urandom to avoid all the end-user questions about the blocking. And the beauty of the Yarrow PRNG is that as long as you have enough initial entropy to get started, you can pull as many bytes as you want and still remain cryptographically strong (within some very high limit of like 2^120 bytes before the next re-keying). Richard Coleman richardcoleman@mindspring.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?407A868F.8040108>