/dev/random vs. /dev/urandom and the krb5 test suite

[Don Davis]

hi, greg --

      have you tried just adding entropy to the pool
during your tests, so that /dev/random won't stall?
running "find / -name foo" on a spare disk ought to
suffice for this.

                                             - don davis, red hat


On 06/18/2009 12:48 AM, ghudson at MIT.EDU wrote:
> The krb5 test suite generates a lot of random keying material.  Under
> the assumption that cryptographic keys require "strong" randomness,
> most of that material comes from /dev/random.  This can create stalls
> in some environments; for instance, my Linux box spends a few extra
> minutes per testing run if I don't use a local hack to make lib/crypto
> use /dev/urandom instead.
>
> Some other developers have run into this recently as well, so we may
> do something about it.  An obvious choice is to add a context flag and
> krb5.conf setting to always use /dev/urandom in favor of /dev/random.
>
> My question is whether to put big red flashing lights around the
> option name or not.  It's possible that some high-load production
> environments are seeing /dev/random stalls as well, although I have no
> particular reason to believe this is so.  If we use a relatively
> innocuous name, people might legitimately find the option useful for
> such cases--or people might set it out of ignorance when it's not
> needed and could cause harm.
>
> If the system PRNG is weak, or if it has been seeded with very little
> true random data (say, 64 bits or less), then using /dev/urandom would
> be disastrous for a system's security.  However, both cases are a bit
> far-fetched today in my opinion.  What I'd like input on is whether
> there are practical risks in the expected cases of using /dev/urandom
> for keys.  For example, say you generate a hundred 128-bit keys with
> your system's /dev/urandom when there are 600 bits of true randomness
> in your system's pool, instead of using 12800 bits of "true"
> randomness from /dev/random as one might like.  An attacker can
> compromise all 12800 bits of keying material with a 2^600 workload, at
> least in theory, but this is not a very interesting attack, especially
> since one of those 128-bit keys is probably of higher value (like your
> TGS long-term key) and would be more interesting to break in
> isolation.  Are there other attacks of interest in this scenario?
>
> Sorry if this is a little long-winded; I'm just trying to choose
> between a judgemental name like "insecure_random" or something more
> bland like "always_use_urandom" for the override.  The default will
> certainly remain the way it is.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>