[Beowulf] Quasi-Non-Von-Neumann hardware in a Beowulf

[Robert G. Brown]

On Fri, 11 Mar 2005, Eugen Leitl wrote:

> On Thu, Mar 10, 2005 at 08:08:17PM -0500, Robert G. Brown wrote:
> 
> > Yeah, I've done all of these computations and looked into various
> > quantum devices and entropy based generators.  However, you'd be
> > surprised how difficult it is to make a HARDWARE based random number
> > device that passes e.g. diehard.  There is a deep truth here.  "Random
> 
> http://www.via.com.tw/en/downloads/whitepapers/initiatives/padlock/evaluation_padlock_rng.pdf
> 
> Support is there starting with kernel 2.6.11.

Yes, and also see the attached, which is pretty much a linear
predecessor of this white paper prepared by the same company for Intel.
The von neumann transformation is what I was referring to as a means of
improving bitlevel statistics, but a) it costs you 1/2 of the total bits
generated to use; b) it only fixes the first moment of the bit
distribution (restores balance between 0's and 1's) but as both papers
empirically note, it doesn't fix either serial correlations due to at
best empirically known autocorrelation patterns or higher order (N at a
time) bit correlations).

Thus it is safe to say that while the sources are unpredictable, they
are not "random" (distributed as random numbers to all orders).  And
they are slow. Or as you say (said) -- good for cryptography, not so
good for simulation, except to seed a decent prng.  However, linux folks
can do just as well for cryptography with /dev/random, which doesn't
require anything at all.  At least that's what I think -- dieharder
doesn't yet support the whole NIST STS suite but I personally think that
a whole lot of both STS and diehard will reduce to a single more direct
test of bitlevel randomness of a generator that I HAVE implemented.

But since none of this is published (yet) and hence referreed, I could
be mistaken.

> > Actually IIRC there was some effort by Intel to build something into a
> > CPU or some other part of a mobo chipset, but I don't know what came of
> > it.  The people who need this commercially are webvolken and encryption
> 
> It's still there in some chipsets, but you can't rely on it being there if
> you don't control your hardware purchases.

This was the origin of the white paper attached -- part of their
original engineering effort, I believe.

> > algorithms, where "unpredictable" is almost as good as "random to the
> > nth bit of randomness".  Nobody uses marginally secure encryption if
> > they can help it.  However, these folks are totally happy with
> > kilorands/sec, let alone megarands/sec.  I need hundreds of
> > megarands/sec.
> 
> http://fp.gladman.plus.com/ACE/
> claims almost 2 GByte/s throughput for AES. The bottleneck will be the GBit
> NIC on a PCI bus.

I'll have to look into this.  If the rands are simulation quality and
the device not too expensive, this could easily be worth it.  This is
the sort of thing I was hoping to turn up in this discussion.

  rgb

> 
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu