----- Original Message -----
From: "Eugen Leitl" <[EMAIL PROTECTED]>
> On Mon, 22 Apr 2002, Tim May wrote:
>
> > What real-life examples can you name where Gbit rates of random digits
> > are actually needed?
>
> Multimedia streams, routers. If I want to secure a near-future 10 GBit
> Ethernet stream with a symmetric cypher for the duration of a few years
> (periodic rekeying from a RNG might help?) I need both lots of internal
> state (the PRNG can't help leaking information about its state in the
> cypher stream, though the rate of leakage is the function of smarts of the
> attacker) and a high data rate.
Actually that's not necessarily the case. Let's use your example of a
Multimedia stream server that is filling a 10GBit/s connection. Right now
the current minimum seems to be 56kbit/s. So that means that if every
available connection is taken in the same second, the server would only need
a rate of 2.2 million bits/sec from it's RNG to build a 128-bit key for
each. A good design for this though has the client doing most of the random
number choosing, where the only purpose of the server random number is to
prevent the client of biasing the result, so 128-bits is more than
sufficient. So 2.2 Mbit/sec seems to be the peak for that. Finding
situations where a decent design will yield a need for an RNG to run about 1
Gbit/sec is extremely difficult. With poor designs it's actually rather
easy, take a RNG that is poor enough (or a situation where that is a basic
assumption) that it has to be distilled to 1 billionth it's size, obviously
to support that multimedia stream server would require 2.2 million Gigabits
per second (approximately).
> > In any case, if someone wants Gbits per second of random numbers,
> > it'll cost 'em, as it should. Not something I think we need to worry
> > much about.
>
> Maybe, but it's neat trying to see how the constraints of 2d and 3d layout
> of cells, signal TOF and fanout issues influence PRNG design if lots of
> state bits and a high data rate are involved. It is not very useful right
> now, agreed.
I think it would be a good process to go through to develop a design for
one, or at least a basic outline for how it could be done, but the basic
idea that comes to mind looks a lot like /dev/random, but run in parallel
collecting from several sources including a custom hardware pool similar to
the Intel RNG.
Joe
