[Cryptography] real random numbers

[Sandy Harris]

Let me a try a different way of stating (what I think is) Denker's point.

>From docs for my RNG, at:
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/

Discussing Denker's Turbid, found at:
http://www.av8n.com/turbid/paper/turbid.htm

(Quoting)
The unique advantage of Turbid is that it provably delivers almost
perfectly random numbers. Most other generators – including mine,
random(4), and the others discussed in this section – estimate the
randomness of their inputs. Sensible ones attempt to measure the
entropy, and are very careful that their estimates are sufficiently
conservative. They then demonstrate that, provided that the estimate
is good, the output will be adequately random. This is a reasonable
approach, but hardly optimal.

Turbid does something quite different. It measures properties of the
sound device and uses arguments from physics to derive a lower bound
on the Johnson-Nyquist noise [3] which must exist in the circuit. From
that, and some mild assumptions about properties of the hash used, it
gets a provable lower bound on the output entropy. Parameters are
chosen to make that bound 159.something bits per 160-bit SHA context.
The documentation talks of “smashing it up against the asymptote”.
{End quote)

The difference is real and it seems quite clear that an RNG with a
provable bound is preferable to one where analysis must rely on
assumptions about or estimates of input entropy. For a rather large
subset of servers -- basically any that have an unused sound card
equivalent or can easily add one -- Turbid should be the first thing
considered for use as an RNG. It is open source, so auditable, and
uses hardware that appears unlikely to be subject to fiddling by
three-letter agencies of any government.

The basic design of RDRAND looks like it could be proven secure in
much the same way, but with the Snowden revelations   plus this paper
http://hardware.slashdot.org/story/13/09/13/1228216/stealthy-dopant-level-hardware-trojans
it becomes harder to trust.

All that said, I still want to use something like Linux random(4) with
a large pool and multiple entropy sources.