From: jimbell@pacifier.com (jim bell)
Date: Thu, 16 Nov 1995 03:12:24 +0800
To: Peter Monta <pmonta@qualcomm.com>
Subject: Re: Hardware-random-bits interface
Message-ID: <m0tFmLF-000912C@pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain


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