Subject: Re: arc4random(9)
To: Perry E. Metzger <perry@wasabisystems.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-security
Date: 05/28/2002 18:12:00
On Tue, May 28, 2002 at 03:55:31PM -0400, Perry E. Metzger wrote:
> 
> As for removing use of rc4 itself, I'd agree it would be good, but I

I'm more concerned that we not add the use of RC4 as a random number 
generator to our kernel *now*.

> think we should take a bit longer to decide on precisely what we want
> done. Your proposal of the use of the X9.31 mechanism sounds like a
> not-so-bad idea, but of course we would have to decide on details. I'd

The way the X9 and FIPS 140 standards are written, we don't really have
much choice about the details at all.  For example, only two generators
are permitted by FIPS 140 at present: a SHA1-based generator which has
some problems, and the 3DES-based feedback generator from X9.31, which 
is required to use 3DES as the block transform.  One of the inputs to
this function is "time" (actually, a 64-bit value that varies with time)
and the other is the previous block of output; lather, rinse, repeat.

Yarrow is *not* permitted; neither is our current generator; neither is
the RC4-based generator from OpenBSD.  If your system uses any of those
generators to key any cryptographic operation (or to generate a nonce) it
probably cannot be FIPS 140 certified.

Neither standard appears to prohibit rekeying the transform periodically
with a value from some external entropy source; how to do so using either
our existing "random pool" implementation or a hardware source, if present,
would seem to be the principal implementation detail to work out.  The
generator is required to do some statistical tests on its output after
rekeying, however; if the output doesn't pass, it has to shut down.

Thor