4

I'm doing some reading into the security issues surrounding /dev/random but it's proving to be hard to find good sources of information. Can anybody help? I've asked Google and got a bunch of articles from pre-2006 so I'm assuming a lot of the issues pointed out there have been fixed. I've also been going through the source but I'm not an encryption or security expert so there's a good chance my personal analysis wont be sufficient. Any help or direction would be greatly appreciated.

EDIT: to make my question more specific, what I want to know about is how the entropy pool is mixed, how the level of the pool is estimated, and how /dev/random actually calculates its values based on what is in the pool. I want to know why things are done how they are done and what are the weaknesses of the methods used. I know how the pool is populated.

My end goal is to implement a TRNG that will populate /dev/random. Now, I can get its output (nice and white) to the pool, I just want to know if it's worth bypassing the pool completely and writing a module to directly populate /dev/random. I'm assuming here that an assailant can poison the pool to mess with the random device output.

At the moment I'm working with Ubuntu, the kernel version is 2.6.32

Improve this question
9
  • 1
    It would help if you mention the specific issues you're wondering about
    – chris
    Sep 12, 2011 at 7:48
  • The only kind of issue I can think of would be predictable random numbers - and of course any such issue that has been publicized is already fixed.
    – Wladimir Palant
    Sep 12, 2011 at 9:15
  • I'm mostly worried about how the pool is mixed, and how random numbers are derived and why
    – Sheena
    Sep 12, 2011 at 11:22
  • 1
    The base paper referred so everybody can get on track as to what vulnerabilities were found the last time: eprint.iacr.org/2006/086.pdf
    – Nakedible
    Sep 13, 2011 at 9:22
  • 3
    there's some interesting commentary on /dev/random and /dev/urandom in the answers to this question security.stackexchange.com/questions/3936/…
    – Rory McCune
    Sep 14, 2011 at 12:46

2 Answers 2

Reset to default
3

For many cryptographic applications, /dev/random is a secure way to gather (pseudo) random data. There are, however, several key issues that seem to be along the lines of what you're asking.

One of the issues is that it is possible to write to /dev/random. According to Wikipedia,

It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/.

This makes sense for a non-compromised machine, however if someone has rooted a box, they could theoretically write non-random data (that appears random) to /dev/random and cause problems with cryptographic keys generated from that point forward. It's tough to determine the severity of such an attack, since if root was already compromised, more significant attack vectors would certainly exist (all software could, at that point, be backdoored).

The second set of issues, detailed in the paper Analysis of the Linux Random Number Generator (March 2006), focuses on problems with saved-state machines. This is primarily found in Linux live-cd's that have the same built-in (read-only) entropy when booting, but in today's world can also apply to virtualized machines that have states restored, or machines using software that can revert to a "known good" state upon shutdown. If the entropy can be determined upon boot, then /dev/random can be compromised (as it is a known starting value).

There are several ways to improve upon the standard /dev/random, the most well-known of which may be the Entropy Gathering Daemon (http://egd.sourceforge.net/). EGD can work as a "userspace substitute" for /dev/random, which can allow applications to have a significantly more secure PRNG.

Lastly, if you are interested in "true random" entropy, consider using a service like Random.org which uses atmospheric noise to create true, not pseudo, random numbers.

Hope this helps!

Improve this answer
4
  • 4
    Using random.org to generate cryptographic keys sounds dangerous. You would need to use HTTPS to secure them on transit, but see the note in their FAQ: anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.
    – Paŭlo Ebermann
    Nov 22, 2011 at 21:00
  • 1
    This is certainly a very valid point. My use case was more along the lines of downloading significant amounts of truly random data and using chunks of it for seeding /dev/random vs. downloading new random data to create each new key. ENG would be more suited towards key creation.
    – dshaw
    Nov 22, 2011 at 21:17
  • 1
    Rooting a box and messing with /dev/random? I wouldn't even bother with such a possibility.
    – Camilo Martin
    Jul 27, 2012 at 13:12
  • -1 for suggesting something as silly as using an online randomness service for these purposes.
    – forest
    Apr 3, 2018 at 4:45
1

Resources:

You can pick the version of interest to you from the top. The source for the software RNG is pretty well commented, so I'll leave interpretation up to you.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .