I do not see anything "reasonable" in the excuses Anonymous
attributes to Intel not allowing access to raw RNG bits. If Intel
wants developers to use their RNG API they need only publish it.
Professional programmers these days respect APIs and realize they
risk future problems if the do not follow them.
I am not sure who a "naive user" of a hardware RNG might be, but I
think courts would consider any software engineer knowledgeable
enough to be responsible for reading the warnings included in the
documentation. And if the raw bits are close to white, the
consequences of using them directly in most cryptographic
applications is negligible. The old "lawyers made me do it" argument
is really thin here.
Finally, the notion that selling a few six-figure driver kits is
material to Intel's bottom line is hard to credit.
Random number generation is a vital part of any security system. It
is important check raw bits regularly to verify, to the extent
possible, that no failure has occurred. Some bias in the raw bits
may be valuable here, particularly if it can be correlated with and
physical parameter such as bus voltage or chip temperature.
Intel's reluctance to publish details of the RNG interface and to
make raw bits available to system designers is troublesome and
suspect.
Arnold Reinhold
At 12:00 AM +0200 9/17/99, Anonymous wrote:
>...
>
>Bram asks:
>
> > If Intel's RNG really is producing a reliable one bit of entropy per one
> > bit of output, why don't they just make it accessible without whitening?
>
>There are a number of reasonable possibilities for why Intel prefers to
>provide the post-whitened output:
>
>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 Intel 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). This issue will therefore probably be moot in a few months.
