What is it?
Entropy Broker is an infrastructure for distributing cryptographically secure random numbers (entropy data) from one or more servers to one or more clients.
Entropy Broker allows you to distribute entropy data (random values) to /dev/random devices from other systems (real servers or virtualised systems). It helps preventing that the /dev/random device gets depleted; an empty /dev/random-device can cause programs to hang (waiting for entropy data to become available). This is useful for systems that need to generate encryption keys, run VPN software or run a casino website. Also virtual systems that have no good sources of entropy like virtual servers (e.g. VMware, XEN and KVM (altough KVM has the virtio_rnd driver)). Using Entropy Broker you can also centralize the entropy gathering to reduce the cpu load on virtual machines. It can also help all software that uses OpenSSL to retrieve secure random data.
Entropy Broker is an infrastructure consisting of client-daemons that fill /dev/random and server-daemons that feed the central Entropy Broker-server. The server-daemons can gather random values by measuring timer frequency noise, analysing noise from a unused audio-device, noise from a video source (webcam, tv-card) and random values from a real hardware RNG (random number generator) like the EntropyKey or RNG devices integrated in Intel/VIA hardware.
How it works
Latest stable release: eb-2.9.tgz
|2.9||compile fixes, 100% cpu fixes|
|2.8||code clean-up, license change (GPL v2 to GNU AGPL v3.0)|
|2.7||stability fixes, added support for the ComScire QNG PQ4000KU, clients can now be read-only|
|2.4||added support for the Araneus Alea I true random number generator|
|2.2||calculation of bandwidth allowance was incorrect|
|2.1||many fixes. also added web-interface for viewing statistics and added per user bandwidth limits|
|1.2||full IPv6 support, bps output fixes, can now retrieve entropy data from smartcards, support for multiple broker servers, EGD server/client now supports TCP as well, fixes for Fedora, coverity warnings fixes
NOTE: IPv4 addresses must have
- Q: it does nothing! the kernel does not get filled!
- A: If you want the kernel buffers to be filled much earlier (the default is when it only has 128 bits left), then write a new value to:
echo 512 > cat /proc/sys/kernel/random/write_wakeup_threshold
- Q: the/a server process exits (immediately)!
- A: If one of the server processes quits after a while (or even immediately), then check its logging to see what the problem is. All processes have the following command-line switches for that:
- Q: why bother?
- A: good random numbers are often required for crypthography. For example for challenge-response process or for the generation of keys. When the random numbers used are predictable (even somewhat!), then bad people might e.g. intercept communications. For example there were problems with fraudulent EMV-card transactions caused by payment terminals using a weak random number generator. Also the Dutch OV Chipkaart had issues due to a predictable RNG. If your webserver uses SSL or you use PGP (or any other crypotooling) or a vpn solution (openvpn, ipsec, etc), then you need good entropy data.
- inventgeek.com - use a radiation-source from a smoke-dector and a webcam for generating random numbers
- fourmilab - another article about generating true random numbers using an radioactive source
- This website: http://www.cs.berkeley.edu/~daw/rnd/ lists a whole lot of links to information on entropy-gathering on computers
- lavarnd.org - generating random values using a lavalamp and a webcam
- RFC 4086 - randomness requirements for security
- Soekris engineering sells a board for aprox. $80 with a hardware RNG on it
- ComScire has an USB solution producing upto 1Mb of random data per second
- Orion has an RS232 solution producing 7.6Kb per second
- hg400 USB2.0 connected hardware RNG. data-rates from 16Mb upto 32Mb
- protego.se an RS232 and USB solution
- qrbg - a USB connected quantum RNG. 12Mb/s
- idquantique - another quantum solution. 4 upto 16Mb