[117603] in Cypherpunks
Re: Build a better OTP?
daemon@ATHENA.MIT.EDU (Anonymous)
Mon Sep 6 22:55:38 1999
Date: Tue, 7 Sep 1999 04:38:10 +0200 (CEST)
Message-Id: <199909070238.EAA30371@mail.replay.com>
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net
Reply-To: Anonymous <nobody@replay.com>
Jim Gillogly writes:
> Sure, I trust Kocher to do a very competent analysis of the thing.
> However, Intel provided the interface specs only to Microsoft, and
> we have to trust them as well as Intel for the post-whitened bits.
> The only way we can trust the output of the RNG is if we can test
> the thing.
Actually, the device driver was written by Intel, not by Microsoft,
and was reviewed by Kocher along with the hardware design. It does have
the ability to detect failure modes of the chip, as described in section
4.6 of Kocher's review.
> Maybe the one Paul tested was fine, but mine is wedged... I'd
> never know the difference, since the output goes through SHA-1
> and presumably something else to provide a history pool -- but I
> might have ablsolutely zero entropy, and somebody who knows the
> state of my computer might be able to take advantage of it.
The chips are tested both during manufacture and during operation.
Based on his analysis of the design, Kocher says that the most likely
failure modes would be stuck bits or simple patterns which would be
caught by the FIPS-140 tests.
> I'll happily stir it into my /dev/random pool, but unless I can
> see the pre-whitened output I won't know a positive value to place
> on the randomness I'm adding.
>
> So why isn't Intel telling? What do they have to hide? Don't
> they know they're not allowed to have privacy any longer?
There are several reasons for Intel's reticence. The main one is that
they want people to access the chip via a standard API which provides
high quality random bits. This is normal software engineering practice.
It gives them freedom in the future to make changes to the chip interface
and accommodate them in the driver. For example, they could move the
von Neumann bias remover into software if they desired, and the change
would be transparent to software which used the chip. Or perhaps they
could go in the other direction and put some kind of SHA-like whitener
onto the chip in order to reduce the software load. Using a standard
API for high quality random bits allows this kind of design flexibility
without concerns about breaking applications which rely on the previous
architecture.
They are also concerned, with the current architecture, that naive users
may use the output of the chip directly without passing it through the
software layers which are necessary to make it fully random. Of course
most people would hopefully not be foolish enough to do this, but Intel
may be worried about liability issues if they publish the internal
interface to a "random number generator" which is not fully random.
Intel is probably also be motivated by profit. Got to keep that stock
going up, you know. Apparently they are charging a great deal of money
(six figures) for access to the RNG library. If they openly published
the interface to the chip they would not be able to make this kind
of money off of their software driver.
Now, although these reasons are all valid to varying degrees, it is
likely that the interface will be published despite these concerns.
There is little that Intel can do to stop people from reverse engineering
their driver and publishing the interface (anonymously, if necessary).
If the interface information does come out in this way, it is actually
not that bad for Intel. They can still feel free to change the interface
with nothing more than a "told ya so" when it breaks Linux. They can't be
sued over an interface that they made a concerted effort to keep secret.
And while they may not be able to rake in megabucks for letting people
use their driver, this was never really in the cards, anyway. It's a
standard marketing trick to shake down the early adopters, and they'd
need to drop the price soon anyway.
