On Fri, 21 Jul 2000, Kris Kennaway wrote:

> > Section 2.1, last paragraph:
> > "If a system is shut down, and restarted, it is desirable to store some
> > high-entropy data (such as the key) in non-volatile memory. This allows
> > the PRNG to be restarted in an unguessable state at the next restart. We
> > call this data the reseed file."

After rereading the paper in more detail, Step 7 of the reseed algorithm
seems not entirely consistent with this: they explicitly refer to writing
out "the next 2k bits of output from the generator to the seed file"
(slightly different terminology, but I couldn't find any other references
to the "seed file")

Another important point is that Yarrow-160 is not useful for generating
keys >160 bits, because of Shannon's theorem and the fact that it uses
SHA-1. You seem to be using a blowfish-based hash function with 256-bit
keysize (do you have a reference for using blowfish in that fashion?), but
the point stands. It seems we would need to use an alternative interface
which either synchronously reseeds with every output to generate stronger
random data, or just taps into the (hashed) entropy pools directly.

This was also a problem with our /dev/urandom (by design), but not with
/dev/random since that tapped the entropy pool directly. Incidentally, it
also looks like a problem with OpenBSD's /dev/arandom which is a stream
cipher (arc4 with 256-bit key) periodically reseeded.


In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to