Date: Sat, 22 Jul 2000 10:04:08 +0200 From: Mark Murray <mark@grondar.za> To: Kris Kennaway <kris@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak Message-ID: <200007220804.KAA05467@grimreaper.grondar.za> In-Reply-To: <Pine.BSF.4.21.0007212105590.88047-100000@freefall.freebsd.org> ; from Kris Kennaway <kris@FreeBSD.org> "Fri, 21 Jul 2000 21:26:06 MST." References: <Pine.BSF.4.21.0007212105590.88047-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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") He doesn't talk about it too much :-(. > 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. Lots of references: Schneier's "Applied Cryptography" talks about using Good Hashes for crypto and Good Crypto for hashes. Schneier's site at www.counterpane.com will give you plenty. It is also an extension and improvement on the way OpenBSD do their bcrypt (passwd) hash. > 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. The differnce with the old system and Yarrow is yarrow's self-recovery property; Yarrow screens its internal state from the ouside world very heavily, and provides enough perturbation of it from its copious :-) entropy harvesting to keep the state safe from compromise. Yarrow also keeps multiple (fast/slow pools + key) states, and the long, slow interactions between those give much better protection that the old system which was pretty much a simple PRNG+simple random perturbations. (I know MD5 is not "simple", but it is deterministic, and was only used once). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007220804.KAA05467>