bind-9.9.5 regression test error
Doug Barton
dougb at dougbarton.us
Mon Feb 24 00:53:03 UTC 2014
On 02/12/2014 10:16 PM, Christoph Moench-Tegeder wrote:
> ## Doug Barton (dougb at 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.
> 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.
> See:
> http://www.metzdowd.com/pipermail/cryptography/2014-February/019920.html
> http://blog.cr.yp.to/20140205-entropy.html
> http://iang.org/ssl/hard_truths_hard_random_numbers.html
Yes, these are all decent posts, and I have no real argument with them
based on a casual reading. However none of them contradict the actual
advice I gave.
> 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.
> Even linux ranodm(4) suggests to use /dev/urandom in most cases, as
> frequent reads on /dev/random will deplete the entropy pool and make
> /dev/random unusuable for those who really need it.
Yes, that's one of the weaknesses of the Linux model vs. Yarrow (and its
successors). It's also why I suggested running haveged. :)
Doug
More information about the bind-users
mailing list