> Charles M. Hannum wrote:
> > Most implementations of /dev/random (or so-called "entropy gathering
daemons")
> > rely on disk I/O timings as a primary source of randomness. This is
based on
> > a CRYPTO '94 paper[1] that analyzed randomness from air turbulence
inside the
> > drive case.
At the last place at which I worked, a few years ago, a "random
number" was generated, and used in a FIPS 140-1 compliant
encryption device, by capturing 128 ethernet frames in sequence
from the local in-house network, gathering the LSB from the
arrival time of each frame, and using those values to generate
an encryption key. This was part of the "activation sequence"
which had to be done, once, on each such device.
Any studies out there on the randomness of such a number?
At first glance a non-deterministic network would seem to be
able to generate a useful number for the key.
> Charles M. Hannum wrote:
> > Most implementations of /dev/random (or so-called "entropy gathering
daemons")
> > rely on disk I/O timings as a primary source of randomness. This is
based on
> > a CRYPTO '94 paper[1] that analyzed randomness from air turbulence
inside the
> > drive case.
At the last place at which I worked, a few years ago, a "random
number" was generated, and used in a FIPS 140-1 compliant
encryption device, by capturing 128 ethernet frames in sequence
from the local in-house network, gathering the LSB from the
arrival time of each frame, and using those values to generate
an encryption key. This was part of the "activation sequence"
which had to be done, once, on each such device.
Any studies out there on the randomness of such a number?
At first glance a non-deterministic network would seem to be
able to generate a useful number for the key.
- Bob Foxworth, GSEC, CISSP
[ reply ]