## Doug Barton (do...@dougbarton.us): > >> If you don't have enough random bits on your system to run these simple > >> tests, your /dev/random is seriously underpopulated, and likely a > >> security risk. You should definitely not put BIND in production compiled > >> with the option you mention above. > > > > Our build/test environment is not our production environment. > > Then what's the point of running the tests? If your test environment > isn't closely mirroring your production environment you're mostly just > wasting time.
Verifiying patches, for example. It's in the nature of our product (think appliance) that we cannot build on the target directly and testing there is somewhat tedious, so we want to get as much coverage as possible before moving to the target. Thinking of it, there're a lot of "production" environments lacking the tools for running tests, or where mucking with the ip addresses on the loopback interface is not possible, so you end up running your tests in a mock environment. > > Further, the ideas about "random numbers for practical purposes" > > have shifted a bit. In short, you don't really need "high real entropy", > > but a stream of numbers *unpredictable to the adversary*. > > Yes, I'm quite familiar with those thoughts, and have some degree of > sympathy with them. You will hopefully have noted that I didn't > recommend hooking up a hardware based source of high-quality entropy to > every name server. What I actually recommended was that Linux systems > run a low-impact, freely available piece of software that helps to stir > the entropy pool so that /dev/random can produce sufficient PRNG bits > without blocking. That's more than adequate for nearly all uses, unless > you're actually doing work which requires a high-quality RNG. I agree tieh that (and still believe that just for running "make test" in a mock environment /dev/urandom is still good enough). > > In fact, on systems like FreeBSD you never get to see the "entropy" > > directly, you only get the output of a PRNG (yarrow in this case), > > which is periodically reseeded with "real entropy". > > Funny you should mention FreeBSD's Yarrow, as I was peripherally > involved in its initial implementation. :) I'm not sure what point > you're trying to make by mentioning that "you never get to see the > 'entropy' directly" though. That's not only a feature, it's a > fundamental part of the design. The point is "the amount of entropy in some pool is not a measure of the quality of the random numbers". The blocking behaviour of linux' /dev/random looks like a relict from times where that point was not universally accepted. But now this is becoming a discussion abount random numbers and their generation - I think this sould be moved off-list? Regards, Christoph -- Spare Space _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
