[Cryptography] Fun with hardware RNGS: the Infinite Noise Multiplier

[Bill Cox]

Actually, the circuit is highly insensitive to noise from non-random
sources.  Simply imagine the digital version, where we shift out one bit
every cycle.  We can add any signal you like at any amplitude, and all it
does is flip bits that are already randomized, making them no less random.
 Coupling with adjacent circuits, RF, and NSA or China inspired signal
injection attacks are all OK.  The only assumption here is the max
amplitude of the injected signal does not move the signal out of the valid
bounds, and I've got about .2V on both ends.  A an attacker capable of
injecting more than .2V may be able to compromise randomness, but that's a
large signal.

The signal from any one channel will be available in raw form for any
software that wants it that way.  On my 1.5 mm^2 die, I fit 16 channels,
along with pads, and a custom microcontroller I designed.  I don't have
enough digial I/Os available to provide all 16 channels at 8MHz at the same
time, but you'll be able to switch between them.

Bill


On Sat, Dec 7, 2013 at 4:33 PM, Jonathan Thornburg <jthorn at astro.indiana.edu
> wrote:

> On Sat, 7 Dec 2013, Bill Cox wrote:
> > Someone asked for some more detail about the design.  I've created a
> simple
> > web page describing the Infinite Noise Multiplier here:
> >
> > http://dev.vinux-project.org/RNG/
>
> I have several (somewhat related) devil's-advocate comments:
> [These actually apply to just about any hardware RNG]
>
> [I should emphasize that I'm *not* trying to be irritating here, i.e.,
> these are meant as *constructive* comments and implicit suggestions for
> how the design might be made more robust.]
>
> (1)
> It's really good that you checked that coupling in a 1 MHz sine wave
> doesn't ruin the randomness.  But what about other nonrandom signals
> coupled in from the environment?  Most real-world environments have a
> lot of RF floating around (not to mention 50/60Hz hum), and it would
> be nice to check a wide range of possible signals and
> places-or-sets-of-places-in-the-circuit-to-couple.
>
> (2)
> Checking for couplings with a spice model is good... but can we be sure
> that the behavior of the actual physical circuit matches that of the
> spice model in this regard?  E.g., does the spice model accurately model
> all the parasitic capacitances between different circuit elements?  If
> not, is there some argument that it's ok to neglect these?
>
> (3)
> If you have multiple copies of the circuit in close proximity, (how)
> do they perturb each other's operation?  Particularly given that they
> probably all share a common clock to avoid Buridan's paradox.  Maybe
> we need some shielding around each circuit?  Or at least some buffer
> amps in the clock tree?
>
> (4)
> Instead of xoring 80 mildly-random bits, why not output them all and
> let software [test them and then] run them through your favorite
> cryptographic hash fn?
>
> The underlying problem in (1), (2), and (3) is that this circuit is --
> by design -- very sensitive to tiny amounts of noise... so we have be
> very paranoid that that "noise" isn't a nonrandom parasitic coupling
> from somewhere else.
>
> ciao,
>
> --
> -- "Jonathan Thornburg [remove -animal to reply]" <
> jthorn at astro.indiana-zebra.edu>
>    Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
>    "There was of course no way of knowing whether you were being watched
>     at any given moment.  How often, or on what system, the Thought Police
>     plugged in on any individual wire was guesswork.  It was even
> conceivable
>     that they watched everybody all the time."  -- George Orwell, "1984"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131207/000fd5d6/attachment.html>