frandom

When compiled into the kernel (as opposed to used as a kernel module), a sysctl() interface is enabled, which makes it possible to grab up to 16 bytes of random data with a single sysctl() call. This requires patching the kernel, not just compiling a package.

An example when this is useful is in the Hardened Linux From Scratch (hlfs), where small chunks of random data are needed very often.

There were two reasons why I wrote this module: First, I wanted to try writing for the kernel for a long time. Unfortunately, I couldn't find anything interesting to write: Everything had been done, and all drivers were working well on my hardware.

And then I attended a lecture by Oleg Goldshmidt at Haifux, the Haifa Linux Club. This lecture dealt with pseudo-number generation. One of the points in the lecture was that /dev/urandom was a good random number generator, but it was slow.

It so happened that I had recently implemented the RC4 crypto algorithm for one of my clients, so I was familiar with the algorithm and how simple it was. After searching in the web, I found that some people actually wanted a faster generator. So I wrote one. With great pleasure, I must say.

The kernel community didn't like the idea of including frandom in the kernel. The interesting thing was that supporting a /dev/frandom device wasn't even on their agenda.

And here's some answers to things you might ask yourself:

• Where can I get it?
  At SourceForge's download page. And you can also have a look at the project's summary page.
• Isn't /dev/urandom enough?
  Discussions about the necessity of a faster kernel random number generator rise and fall since 1996 (that I know of). My opinion is that /dev/frandom is as necessary as /dev/zero, which merely creates a stream of zeroes. The common opposite opinion usually says: Do it in user space.
• What's the difference between /dev/frandom and /dev/erandom?
  In the beginning I wrote /dev/frandom. Then it turned out that one of the advantages of this suite is that it saves kernel entropy. But /dev/frandom consumes 256 bytes of kernel random data (which may, in turn, eat some entropy) every time a device file is opened, in order to seed the random generator. So I made /dev/erandom, which uses an internal random generator for seeding. The "F" in frandom stands for "fast", and "E" for "economic": /dev/erandom uses no kernel entropy at all.
• How fast is it?
  Depends on your computer and kernel version. Tests done so far show 10-50 times faster than /dev/urandom. On a 2.4 kernel running on i686, no more than 10 times faster should be expected.
• Will it work on my kernel?
  It most probably will. It has been tested on 2.2.25, 2.4.18 and 2.6.0-test4, and has a very basic interaction with the kernel in general. It's expected to work on any kernel from 2.2 and on.
• Is it stable?
  Since releasing the initial version in fall 2003, there has been zero crash reports, and nothing more serious than compilation problems. So it's very unlikely to crash your system.

  At least 100 people have tried it (probably many more). It appears to work well on i386 systems. As for randomness, there haven't been any complaints either.

• How is random data generated?
  frandom is based on the RC4 encryption algorithm, which is considered secure, and is used by several applications, including SSL. Let's start with how RC4 works: It takes a key, and generates a stream of pseudo-random bytes. The actual encryption is a XOR operation between this stream of bytes and the cleartext data stream.
  Now to frandom: Every time /dev/frandom is opened, a distinct pseudo-random stream is initialized by using a 2048-bit key, which is picked by doing something equivalent to reading the key from /dev/urandom. The pseudo-random stream is what you read from /dev/frandom.
  frandom is merely RC4 with a random key, just without the XOR in the end.
• Does frandom generate good random numbers?
  Due to its origins, the random numbers can't be too bad. If they were, RC4 wouldn't be worth anything.
  As for testing: Data directly "copied" from /dev/frandom was tested with the "Diehard" battery of tests, developed by George Marsaglia. All tests passed, which is considered to be a good indication.
• Can frandom be used to create one-time pads (cryptology)?
  frandom was never intended for crypto purposes, nor was any special thought given to attacks. But there is very little room for attacking the module, and since the module is based upon RC4, we have the following fact: Using data from /dev/frandom as a one-time pad is equivalent to using the RC4 algorithm with a 2048-bit key, read from /dev/urandom.
  Bottom line: It's probably OK to use frandom for crypto purposes. But don't. It wasn't the intention.