I found a very simple noise generator, slightly tweaked the schematics,
and built and tested it. As far, it seems it performs quite well, though
the data need quite a lot of whitening.
Conn1 R1
+12V O--/\/\/--*-------*---------------------*-------+
| | | |
O + | C1 \ \ \
----- /R2 /R3 /R4
O--+ ----- \ C2 \ \ C3
| | | | | | | | | Conn2
O | | *-----------*---| |---* *----| |---*------O
| | |_ | | | | | | | |
| | |\ / | / | +--O
----- ----- \| |/ | |/ | |
Q1 |---| Q2 +---| Q3 | *--O
/| |\ |\ | |
/ _\| _\| +---|--O
| | |
| | |
----- ----- -----
Q1, Q2, Q3: more or less any NPN transistor (tested with BC338 and KC509)
R1: 270 ohm
R2, R4: 5.3k (4.7k should do)
R3: 1M
C1: 100uF
C2, C3: 100nF
Conn1: Harddrive power connector
Conn2: 4-pin connector like the motherboard ones
Connection to the computer: Power is supplied through Conn1. Noise is fed
into the soundcard into the CD-IN input on the motherboard, using the
audio cable otherwise connected to the CDROM audio-out.
Advantages: Low cost, small board, negligible cost, can be built in a
while from immediately available parts. Uses input devices and cables that
are already present in the computer. Should produce enough entropy to feed
a small home- or smaller-business-grade server, utilizes the integrated
soundcard present on virtually all modern motherboards which gets
otherwise wasted on a server machine.
Disadvantages: Not-really-cryptographical-quality noise (the output value
histogram looks something between bad and awful, "stan"
(stan-0.3.tar.gz) and "ent" (from www.fourmilab.ch/random/) statistical
analyzers show 5.6 bits of entropy per byte for data captured in 8-bit
mode and 6-7 bits per byte for 16-bit mode; but after 128-to-16 hashing it
improves to over 7.9999 bits per byte). Needs a lot of whitening, could be
a disadvantage for high-profile high-grade servers (though these deserve
something better than $2 hardware).
To take full advantage of this toy, makernd.c wants to be patched with
ioctl()s for switching the soundcard to 16-bit mode and 44 kHz samplerate.
Alternately, it can take the random input from stdin instead; then we can
ignore all the ioctl stuff and use sox to pull the data from the DSP with
the required format and samplerate (or from just ANY other device) and for
the user-friendliness we can call it through some wrapper script.
Peer review welcomed thankfully. :)
