frandom

Frandom is a Linux kernel random number generator, which is 10-50 times faster than what you get from Linux’ built-in /dev/urandom. And it uses very little (/dev/frandom) or none (/dev/erandom) of the kernel’s entropy pool, so it is very useful for applications that require a handy source for lots of random data.

Its most common use seems to be wiping large hard disks with random data before encryption. It’s currently supporting 2.6 kernels, but was originally written for version 2.2.

Download the kernel module tarball.

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

• 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 consistently show 10-50 times faster than /dev/urandom.
• Will it work on my kernel?
  It most probably will, if it’s > 2.6.
• Is it stable?
  Since releasing the initial version in fall 2003, at least 100 people have tried it (probably many more) on i686 and x86_64 systems alike. Successful test reports have arrived, and zero complaints. So yes, it’s very stable. 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.