I've been thinking about physically random bits recently, so I'd like to offer a simple, easily implementable interface to a source of such bits, along with a design sketch using a common radio receiver chip as the noise source. The interface consists of two bits in the standard PC parallel port, one serving as the data line and the other the sampling clock. [stuff deleted]
Device probing: the device should somehow identify itself as a random bit generator. One way to do this is to wire one of the parallel port data bits to a status line; for example, data bit 0 (pin 2) could be wired to status bit 5 (pin 12). Software can then twiddle the data bit and watch for the response.
I'm not a crypto expert, or a mathematician, or anything like that, but I think I have a few suggestions that you should consider. 1. DON'T let the random-number generator "know" that it is being accessed, even with something as simple as a clock. The reason is that if it became important enough, an agency with a BIG BUDGET could make a custom chip that implemented the same apparently-random function, (but might really be a 10**18 state machine with, say, only 10**6 starting positions) but could be "alerted" and reset by a specific pattern of external accesses, possibly activated by a special-purpose virus. The resulting "fake" chip would appear to result in random output, if never reset, but would produce a data stream with a predictable series with a limited number of starting points. 2. Since the main goal of the project is to have this end up being an ECONOMICAL board, you'll probably end up with a data stream which has some sort of slight bias in one direction or another. As far as I can see, that's okay, because it merely means that you're getting somewhat less than one bit of randomness with each accessed bit. But as I understand it, the solution to this is to combine the bits in software so that you end up with fewer bits. While it's been months since I've read Schneier's book, I recall that it talked about extracting more-perfectly-randomized bits from a larger collection of not-quite-so-randomized ones. 3. In addition, for most trustworthy results, I think you should XOR the resulting data with a long-period pseudorandom stream of bits derived and modified from some reasonably random inputs, such as keystroke timings and free-running-system-clock bits. The reason is that (as far as this neophyte knows) a stream of GOOD randomized numbers XOR'ed with a stream of reasonably randomized numbers results in a stream at least as randomized as the better source. More importantly, such a procedure should help deter any attempt to corrupt the physically-random source, because even going to that trouble of subverting it they'd only defeat only one stage in the process. 4. I think the user should be given the option of socketing the IC's. True, that would make it easier for an interloper to replace, but it would also allow the user to quickly swap the critical chips, possibly at intervals of a few days to a few weeks, to partially guard against sabotage. 5. The whole assemblage should be able to be stored in a package sealed with evidence tape.