[4091] in cryptography@c2.net mail archive
Re: Intel announcements at RSA '99
daemon@ATHENA.MIT.EDU (Arnold G. Reinhold)
Fri Jan 29 09:45:10 1999
In-Reply-To: <Pine.LNX.4.05.9901281303300.7541-100000@darwin.adni.net>
Date: Fri, 29 Jan 1999 09:19:42 -0500
To: "David R. Conrad" <drc@adni.net>
From: "Arnold G. Reinhold" <reinhold@world.std.com>
Cc: cryptography@c2.net
At 1:13 PM -0500 1/28/99, David R. Conrad wrote:
>
>People doing Monte Carlo methods would be more than adequately served by
>using the kind of PRNGs they currently use, seeded by 32 or 64 truly
>random bits from this thing, no?
>
I do not want to speak for that community, but I do not believe that the
seed is the problem at all, it is the quality and speed of the PRNG.
>People doing serious cryptography also need small chunks of bits --
>perhaps a random 64-bit IV, maybe a 112- or 128- or 160- or 192-bit random
>session key, or a random starting point to look for some big primes.
>
>A driver Yarrowing[1] bits from this true RNG at 1/s, running on a system
>with, say, a 30 day uptime, would have collected 2,592,000 bits of entropy
>over its lifetime. (From the chip, assuming it gets a bit each second.
>It may not get every bit the chip has available, but it would certainly
>get some entropy from other places as well.)
>
I suspect that there will be a need for machines that are ready to transact
within a second or so of being powered up.
>Perhaps you don't want to trust any software at all. But surely you
>intend to do some whitening of the underlying bitstream? In part of your
>message which I cut you clearly foresaw that the bitstream wouldn't have a
>flat distribution of 0s and 1s, which means it needs some whitening.
>Using SHA-1, perhaps? But now we're back to the "many unproven
>mathematical assumptions underlying cryptography".
>
In designing secure systems, the fewer things one has to trust the better
and simplicty leaves less room for errors. One can come up with whitening
algorithms that are mathematically provable, given some model of the
underlying physical RNG process. One might even be able to prove stuff
about SHA-1 in this connection. As you point out in another post, you want
an RNG to fail hard. A whitening routine could detect this and generate an
exception. SHA-1 may not be the right algorithm to use.
In some sense this whole RNG bit rate argument is silly. Since we get along
just fine without an on-chip RNG, how can we say we need any particular
speed.
"Trust everyone but brand your cattle."
Arnold Reinhold
