Bram Cohen wrote:
On Wed, 19 Sep 2001, Peter Fairbrother wrote:
Bram Cohen wrote:
You only have to do it once at startup to get enough entropy in there.
If your machine is left on for months or years the seed entropy would become
a big target. If your PRNG status is compromised
On Thu, 20 Sep 2001, Nomen Nescio wrote:
If the internal circuitry did output a 60Hz sine wave then regularities
would still be visible after this kind of whitener. It is a rather
mild cleanup of the signal.
It does mask patterns to an extent, possibly pushing them inside the
margin for
Ted Tso writes:
It turns out that with the Intel 810 RNG, it's even worse because
there's no way to bypass the hardware whitening which the 810 chip
uses. Hence, if the 810 random number generator fails, and starts
sending something that's close to a pure 60 HZ sine wave to the
whitening
Bill Frantz wrote:
At 2:17 PM -0700 9/19/01, Theodore Tso wrote:
It turns out that with the Intel 810 RNG, it's even worse because
there's no way to bypass the hardware whitening which the 810 chip
uses.
Does anyone know what algorithm the whitening uses?
Just like von Neumann's unbiasing
On Tue, 18 Sep 2001, Pawel Krawczyk wrote:
On Mon, Sep 17, 2001 at 01:44:57PM -0700, Bram Cohen wrote:
What is important, it *doesn't* feed the built-in Linux kernel PRNG
available in /dev/urandom and /dev/random, so you have either to only
use the hardware generator or feed
On Wed, Sep 19, 2001 at 01:12:44AM -0700, Bram Cohen wrote:
not necessary in general case
Since most applications reading /dev/random don't want random numbers
anyway?
Here I meant exactly what you said about /dev/random religion. On the
other hand feeding the /dev/random with i810 during
At 1:12 AM -0700 9/19/01, Bram Cohen wrote:
Of course, there's the religion of people who say that /dev/random output
'needs' to contain 'all real' entropy, despite the absolute zero increase
in security this results in and the disastrous effect it can have on
performance.
If I am generating one
Bram Cohen wrote:
On Tue, 18 Sep 2001, Pawel Krawczyk wrote:
[..]
It's not that stupid, as feeding the PRNG from i810_rng at the kernel
level would be resource intensive,
You only have to do it once at startup to get enough entropy in there.
If your machine is left on for months or years
The real-RNG in the Intel chip generates something like 75 kbits/sec
of processed random bits. These are merely wasted if nobody reads them
before it generates 75kbits more in the next second.
I suggest that if application programs don't read all of these bits
out of /dev/intel-rng (or whatever
On Wed, 19 Sep 2001, Peter Fairbrother wrote:
Bram Cohen wrote:
You only have to do it once at startup to get enough entropy in there.
If your machine is left on for months or years the seed entropy would become
a big target. If your PRNG status is compromised then all future uses of
- Original Message -
From: Theodore Tso [EMAIL PROTECTED]
To: John Gilmore [EMAIL PROTECTED]
Cc: Pawel Krawczyk [EMAIL PROTECTED]; Bram Cohen
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 20, 2001 5:17 AM
Subject: Re: chip-level randomness
Bram,
I need _lots_ of random-looking bits to use as covertraffic, so I'm using
continuous reseeding (of a BBS PRNG) using i810_rng output on i386 platform
as well as other sources (the usual suspects plus CD latency plus an
optional USB feed-through rng device a bit like a dongle). I don't use
On Mon, Sep 17, 2001 at 01:44:57PM -0700, Bram Cohen wrote:
What is important, it *doesn't* feed the built-in Linux kernel PRNG
available in /dev/urandom and /dev/random, so you have either to only
use the hardware generator or feed /dev/urandom yourself.
That's so ... stupid. Why go
On Sat, Sep 15, 2001 at 10:16:27AM -0700, Carl Ellison wrote:
I'm told that the LINUX 2.4 kernel comes with the RNG driver
built-in, but I haven't tried that.
It works almost out of box, kernel detects the chip and if you have the
necessary device file created (character 10,183 AFAIK) you can
R. A. Hettinga wrote:
I'm rooting around for stuff on hardware random number generation.
RFC 1750 is a standard reference. There's a draft of a rewrite on ietf.org.
More specificially, I'm looking to see if anyone has done any
entropy-collection at the chip-architecture level as part of
15 matches
Mail list logo
