From owner-freebsd-current Sat Jul 22 1: 4:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 811B237B69C; Sat, 22 Jul 2000 01:04:10 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id KAA05467; Sat, 22 Jul 2000 10:04:08 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007220804.KAA05467@grimreaper.grondar.za> To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak References: In-Reply-To: ; from Kris Kennaway "Fri, 21 Jul 2000 21:26:06 MST." Date: Sat, 22 Jul 2000 10:04:08 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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