[4078] in cryptography@c2.net mail archive
Re: Intel announcements at RSA '99
daemon@ATHENA.MIT.EDU (Eric Murray)
Wed Jan 27 13:07:25 1999
Date: Wed, 27 Jan 1999 08:18:54 -0800
From: Eric Murray <ericm@lne.com>
To: Colin Plumb <colin@nyx.net>
Cc: smb@research.att.com, ben@algroup.co.uk, cryptography@c2.net,
geer@world.std.com, honig@sprynet.com, jamesd@echeque.com
In-Reply-To: <199901270005.RAA10056@nyx10.nyx.net>; from Colin Plumb on Tue, Jan 26, 1999 at 05:05:24PM -0700
On Tue, Jan 26, 1999 at 05:05:24PM -0700, Colin Plumb wrote:
> Steve Bellovin wrote:
> > What I was told at RSA was that the SHA-1 whitening was done by the driver.
> > The driver (I think it was the driver, rather than the hardware) also does
> > its own quality checks on the hardware RNG.
>
> Ah, good, somebody at Intel gets the point.
It's the only way- the chip processes which produce randomness
aren't understood well by fab process people, and the h/w rng isn't
testable on the production line.... chip test machines only deal
with known inputs and outputs.
Also, the h/w rng could possibly fail in use. So periodic
testing is required (for some applicable value of 'periodic' and 'testing').
> But I still think that given a reasonable amount of seed material,
> I can do cryptographic "reprocessing of spent fuel" basically forever
> with good security. More is nice, but I do think that 1 bit per second
> is all that is *necessary* for 95% of the benefit.
You need to have a large enough pool of random seed material at some
point very soon after startup, in case the user boots and immediately
runs a transaction or some other process which needs random numbers.
So it would need to have a higher rate just to cover immediate
use after boot. In a system with a disk you can keep a random pool
around between boots, reducing the first-time problem to the first
boot-up. But that's not an option in embedded or diskless situations.
--
Eric Murray N*Able Technologies www.nabletech.com
(email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
