[117712] in Cypherpunks
Re: Build a better OTP?
daemon@ATHENA.MIT.EDU (Sean Roach)
Thu Sep 9 09:34:40 1999
Message-Id: <3.0.6.32.19990909081720.007fedd0@mail.intplsrv.net>
Date: Thu, 09 Sep 1999 08:17:20 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
In-Reply-To: <199909090659.IAA24393@mail.replay.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Sean Roach <roach_s@mail.intplsrv.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 08:59 AM 9/9/99 +0200, Anonymous wrote:
>
> >> [...RNG whitening code...]
>
> > Well, putting it on the chip sure ain't the right place.
>
>Why do you say that? It seems like it has a lot in common with
>the microcode I write for PowerPC devices here at Motorola.
>
>When a designer buys an MPCxxx, she can use all the functions of
>the chip -- even those that need the microcode to work -- with her
>choice of operating system, libraries, and applications -- without
>compromising Motorola's control over the hardware or the microcode.
Let me ask a few stupid questions here, since the subject has been
brought up.
How much does the ability to process firmware affect the number of
transistors needed for a chip? How hard would it be to use the
existing capacity of the chip to access the RNG? Someone said
something that suggested it was not with the rest of the logic.
Something about that particular feature being on some BUS. How would
implementing whitening in microcode affect price? Could we trust the
whitening more if it were "in hardware" than in a driver?
Granted, my knowledge of programming languages doesn't go any lower
than C++, but I would think even true "machine language" would not be
as clean a design than if the whole process were burned directly into
the chip as raw hardware. That could be because the one example I've
seen of programmable logic consisted of , and that thing was
convoluted compared to what the same chip might have been as simple
logic.
Also, is a driver significantly less efficient than microcode or
would the tradeoff be balanced by the fact that the average user,
even the average paranoid, or most addicted gambler, would not use
the random number generator all that much in comparison to the other
functions of the chip, thus actually saving cycles by not having the
whitened numbers supplied when they are not needed?
Personally, as far as security, I can't see a difference between
trusting an un-peer reviewed, if that is the case, software driver
and trusting an un-peer reviewed firmware driver except that the
software driver could be replaced either by the company to improve
features or by the men in black pullovers to bypass the RNG for
something more predictable. I think that if they could replace my
drivers at will, it wouldn't matter if the driver chosen was my RNG
whitener or my keyboard interface.
I agree that it would be nice to be able to look at the bits first to
see if they at least appeared to be random, but if the whitener was
on the chip, how would that change the arguments for it being open
source?
Someone said that the RNG was one oscillator feeding off another
oscillator. That, to my untrained ears sounds like 4 transistors.
Or about the hardware of 2 bits of memory if one bit is a bi-stable
multi-vibrator, or less than 1, if the text open in my lap can be
relied on and d-latches are used. It sounds almost like it was as
cheap to implement the RNG as to not.
Again, these are my uninformed opinions.
Sean Roach
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN9ezX5HDoiHtqFDZEQJWSQCZASQiV+HZzYRPDYzdYyZaOXSUtiQAnj74
Y49Jt3HBHKoGyem365cHuBws
=Fb+c
-----END PGP SIGNATURE-----
