[117683] in Cypherpunks
Re: better mouseplops
daemon@ATHENA.MIT.EDU (Rabid Wombat)
Wed Sep 8 23:12:16 1999
Date: Wed, 8 Sep 1999 22:46:39 -0400
From: Rabid Wombat <wombat@mayhem.snakecult.org>
To: cypherpunks@algebra.com
In-Reply-To: <199909090043.CAA17009@mail.replay.com>
Message-ID: <Pine.SGI.4.10.9909082243130.19047-100000@mayhem.snakecult.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: Rabid Wombat <wombat@mayhem.snakecult.org>
... and, of course, Intel can easily modify, er, upgrade the whitening on
down the road, for better or worse, if implemented in the driver. Not that
I'm paranoid or anything, I just *look good* in a tinfoil hat.
On Thu, 9 Sep 1999, Anonymous wrote:
> Anonymous #1, #2 are both on crack. It doesn't matter where (hardwired
> logic, firmware, software) you do the conditioning. What matters is that
> the user can monitor the bits *before whitening* so as to ascertain their
> true unpredictability.
> before cooking them up.
> ('Cause after whitening, there is no possibility of such
> measurement.)
>
>
>
> At 12:03 AM 9/9/99 +0200, Anonymous wrote:
> > >> My point was that it's bad engineering practice for Intel to
> > >> design a hardware RNG that requires an OS-specific API.
> >
> > > But Intel didn't design a hardware RNG that requires an
> > > OS-specific API. They could make a Linux API without any problem.
> >
> >But that *is* an OS-specific API -- simply a different OS.
> >The entire argument of one OS vs. another is a red herring,
> >and entirely irrelevant to my argument. I argue that Intel
> >should have placed the RNG whitening in microcode instead of
> >into and OS driver, thus avoiding the entire OS issue altogether.
> >
> > > Once again we have an ideologically based objection which ignores
> > > the reality of engineering constraints in the real world.
> >
> >Rubbish. I'm claiming that good engineering practice suggests
> >that an OS driver is the wrong place for RNG whitening code.
> >
> >
>
>
>
>
>
>
>
>
>
>
>
