/dev/random vs. /dev/urandom and the krb5 test suite
ghudson at MIT.EDU
Mon Jun 22 15:38:13 EDT 2009
Since this thread has died, a summary of the outcome:
* We only use /dev/random for long-term keys, not for short-term keys
generated as a result of traffic to the KDC.
* There isn't much operational reason why you'd want to suppress the use
of /dev/random in favor of /dev/urandom for all keys. There was one
report (from iastate) of a case where a server was so random-starved as
to be unable to start kadmind, but using /dev/urandom in that case would
be dangerous because the amount of entropy present might be so low as to
be attackable. So we are talking purely about an option to be used to
make the test suite friendlier to hosts with limited amounts
of /dev/random entropy.
* A couple of people suggested external methods of generating entropy
for the test suite (triggering filesystem or I/O operations) but those
methods are dissatisfying from a robustness perspective.
* Since we only call for /dev/random in two places (kdb5_util and
kadmind), we don't need the knob for this to live inside the library.
* There is some resistance to using an environment variable for this
purpose, since they can leak into production more easily than other
knobs. More universally acceptable options include command-line
switches to kadmind/kdb5_util, or a krb5.conf option.
* Regarding my original question, as a group we are not aware of any
specific attacks on using /dev/urandom to generate cryptographic keys
unless the amount of entropy available is so small as to permit a brute
force attack on the entire PRNG stream. However, that question is
largely moot based on the earlier summary points.
Thanks for the input. It is likely that either Tom or I will implement
something taking all of this into account.
More information about the krbdev