[PYTHON-CRYPTO] /dev/random vs. /dev/urandom

[Mark McEahern]

I recently learned the difference between /dev/random and /dev/urandom--the
former blocks waiting for sufficient entropy while the latter never blocks.
Fwiw, there's a decent explanation here:

  http://old.lwn.net/2001/0823/kernel.php3

There's no internal anchor to the section on /dev/random, but you can search
for this heading:

  Feeding entropy from network devices.

Also, I've appended the text to the bottom of this message.

Apparently, the practical effect is that sometimes using /dev/random takes
longer, but no one has demonstrated an attack against /dev/urandom.

Nonetheless, I noticed in the recently released pycrypto-1.0a2
(http://www.amk.ca/python/code/crypto.html), the randpool.py initializes
with /dev/urandom rather than /dev/random.  That leads to two questions:

1.  Should the selection of which random device to use be optional?
2.  Should the code try to use /dev/random first, and if that doesn't exist,
use /dev/urandom?  Or am I being overly sophomoric?

E.g.,

  import os

  preferred_device = "/dev/random"
  alternate_device = "/dev/urandom"

  random_device = None
  if os.path.exists(preferred_device):
    random_device = preferred_device
  elif os.path.exists(alternate_device):
    random_device = alternate_device
  if random_device:
    try:
      f = file(random_device)
      data = f.read(self.bytes)
      f.close()
      self._addBytes(data)
    ...

Cheers,

// mark

Excerpted from http://old.lwn.net/2001/0823/kernel.php3

Feeding entropy from network devices. The Linux kernel provides two
pseudo-devices which generate random numbers: /dev/random and /dev/urandom.
They both provide (seemingly) random numbers to applications, but they
differ in one regard: /dev/random works much harder to ensure that the
returned numbers are truly random.

The random number generator works through the maintenance of an "entropy
pool," a collection of random data which has been collected from outside
sources. The most common source of entropy (randomness) in Linux systems is
device interrupts; the time periods between keystrokes or disk interrupts is
unpredictable enough to provide a degree of true randomness that can not be
had from a software-only random number generator. Each random event adds a
certain amount of entropy to the pool. If an application reads random data
from /dev/random, the kernel will make sure that there is sufficient entropy
in the pool to return truly random numbers; if the entropy is inadequate,
the read will block until sufficient entropy has been generated.
/dev/urandom, instead, will generate numbers (using a secure hash algorithm)
regardless of whether sufficient entropy exists; it never blocks waiting for
entropy.

In theory, that difference means that a sufficiently clever attacker could,
perhaps, predict the random numbers that will be generated by /dev/urandom.
Using the predicted numbers, the attacker could proceed to make a mess of
any cryptographic or security code using /dev/urandom. Such an attack
remains entirely theoretical, however; it would be in no way easy, and
nobody has ever demonstrated a way of successfully predicting Linux's random
numbers.

Nonetheless, people worry, and many applications will only use random data
from /dev/random. On some systems, this can lead to problems if the system
is not generating enough entropy; suddenly ssh connections take a long time
to start up, and things get unresponsive in general. Network firewalls, with
no keyboard and little or no disk activity can be especially susceptible to
this problem.

The answer, seemingly, would be to use the arrival of network packets as
another source of entropy. Historically, this source of entropy has been
avoided, since network traffic is susceptible to observation and
manipulation by an attacker. In a highly paranoid world, one might worry
about an attacker watching network traffic in an effort to predict the
contents of the entropy pool on a target system; the attacker could also
feed precisely-timed packets to the target in the hopes of influencing
random number generation there. Once again, nobody has ever gotten close to
demonstrating an attack of this nature, but if security people didn't worry
they would have little to do.

Now, however, Robert Love has submitted a patch which allows the system to
use entropy from network traffic, subject to a kernel configuration option.
There is some real opposition to the patch; some people feel that network
entropy should not be treated as entropy at all, and that applications
should just be using /dev/urandom in these cases. The wider consensus,
however, is that sometimes network entropy is the best you can get, and that
it makes sense to give the user a choice of whether to use it. After all,
when, ten years from now, some super cracker develops a network entropy
exploit, you can always turn the feature off.



-