[117699] in Cypherpunks
Re: Build a better OTP?
daemon@ATHENA.MIT.EDU (Anonymous)
Thu Sep 9 02:20:00 1999
Date: Thu, 9 Sep 1999 08:03:20 +0200 (CEST)
Message-Id: <199909090603.IAA17516@mail.replay.com>
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net
Reply-To: Anonymous <nobody@replay.com>
> Rubbish. I'm claiming that good engineering practice suggests
> that an OS driver is the wrong place for RNG whitening code.
Well, putting it on the chip sure ain't the right place. Arguably you
can leave it for the application to whiten it, but in practice that is
just going to end up in a library anyway. You don't want every person
to write their own whitening code. And believe it or not, the majority
of libraries are still not released in source form.
Driver or library makes no difference to the real issue here. This is
a red herring.
What are the real issues?
- Does Intel have a legitimate reason for not wanting to release the
hardware interface specs to the RNG?
- Is it reasonable from the security perspective to use an RNG which
is accessed only through a driver/library which is not available in
source form? Several sub-issues here:
- Is the design fundamentally sound, does the chip produce good quality
random numbers and does the driver handle them properly?
- How likely is a future design change which would either
accidentally or intentionally weaken the RNG?
- How likely is a chip malfunction which produces low quality random
numbers without the failure being detected by the supplied driver?
- What are alternative sources of random numbers, and how do they
compare in terms of security and quality?
- How do the answers above change if/when the hardware interface is
revealed, either by Intel or by reverse engineering the software?
- To what degree are we already forced to trust the hardware and software
that we use? Is the need to trust an RNG any worse than having to
trust the CPU and other peripheral chips?
