On 02/12/2014 10:16 PM, Christoph Moench-Tegeder wrote:
## 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.
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
_______________________________________________
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