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. The parallel port, while a bit less universal than RS-232, eliminates the complexity of UARTs and clock generation and offers higher speed and friendlier local power. For an ISA bus running at 8 MHz, bits can be sampled at about 2.5 Mb/s, i.e., about 300 kB/s. (The bandwidth of the noise source should of course be consistent with this.) Another advantage of a simple device is that it can be thoroughly inspected: there is no PLD or microcontroller code to vet/trust. Not all parallel ports have bidirectional data registers, so the most general path is to assign a status bit to the input and use a control bit for the clock output. I'm using bit 4 of the status register (pin 13 on the PC's DB-25) as the input and bit 0 of the control register (pin 1) as the clock. Specifically, the rising edge of pin 1 should sample the noise waveform and present the result on pin 13. (Pin 1 is inverted, so bit 0 should transition from 1 to 0.) I'd also like to suggest a device name for the Unix environment, /dev/prandom, for "physically random". The intention is that the bits returned be as raw as possible, as close to the physics as possible, leaving any debiasing/hashing to other software (for example, the /dev/random implementation in recent Linux kernels). (I have a Linux device driver that implements this interface; it is very simple, needing only to sample the bits, pack them into bytes, and manage mutual exclusion, filesystem housekeeping, and probing.) Here are the particulars of the "dongle" board I'm in the process of making. Noise source: an FM/IF radio receiver chip, with no input supplied, so that the IF amplifier chain produces wideband noise at its output. I'm looking at the Motorola MC13158 and the Philips SA626. Each provides about 20 MHz of IF bandwidth, and the Motorola part has an on-chip comparator, reducing the entire device to two chips: the receiver chip and an HCMOS flip-flop. Power: from the port data lines; >=3.5V at about 20 mA is available. 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. Cost: around $10 in parts, I guess. A rate of 300 kB/s will make a 600 MB one-time pad in an hour (assuming software is similarly fast). I'm wondering if any of the mail systems have convenient hooks to use pads (though it would not be difficult to write up). Suggestions welcome. I'll put the design on the Web once it's finished; replicating it should be pretty easy. People can also grab the device driver if they wish. Cheers, Peter Monta pmonta@qualcomm.com Qualcomm, Inc./Globalstar