How to disable a Linux entropy pool source

Question

How do I disable entropy sources?

Here's a little background on what I'm trying to do. I'm building a little RNG device that talks to my PC via USB. I want it to be the only source of entropy used. I'll use rngd to add my device as a source of entropy.

Answer 1

Quick answer is "you don't".

Don't ever remove sources of entropy. The designers of the random number generator rigged it so any new random bits just get mixed in with the current state.

Having multiple sources of entropy never weaken the random number generator's output, only strengthen it.

The only reason I can think to remove a source of entropy is that it sucks CPU or wall-clock time that you cannot afford. I find this highly unlikely but if this is the case, then your only option is kernel hacking. As far as hacking the kernel goes, this should be fairly simple. Just comment out all the calls to the add_*_randomness() functions throughout the kernel source code (the functions themselves are found in drivers/char/random.c). You could just comment out the contents of the functions but you are trying to save time in this case and the minuscule time the extra function call takes could be too much.

Answer 2

One solution is to to run separate linux instance in a virtual machine.

Answer 3

I suspect you might want a fast random generator.

Edit I should have read the question better

Anyways, frandom comes with a complete tarball for the kernel module so you might be able to learn how to build your own module around your USB device. Perhaps, you can even have it replace/displace /dev/urandom so arbitrary applications would work with it instead of /dev/urandom (of course, given enough permissions, you could just rename the device nodes and 'fool' most applications).

---

You could look at http://billauer.co.il/frandom.html, which implements that.

• 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.

Answer 4

Additional note, too big for comment:

Depending on its settings, rngd can dominate the kernel's entropy pool, by feeding it so much data, so often, that other sources of entropy are mostly ignored or lost. Do not to that unless you trust rngd's source of random data ultimately.

• http://man.he.net/man8/rngd