From owner-freebsd-current Sun Jul 23 0:39:52 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 B17C237B9A6; Sun, 23 Jul 2000 00:39:41 -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 JAA94403; Sun, 23 Jul 2000 09:39:30 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007230739.JAA94403@grimreaper.grondar.za> To: Kris Kennaway Cc: "Jeroen C. van Gelderen" , current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak References: In-Reply-To: ; from Kris Kennaway "Sat, 22 Jul 2000 17:41:15 MST." Date: Sun, 23 Jul 2000 09:39:30 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Okay, using RSA keys wasn't the best example to pick, but Yarrow also > seems easy to misuse in other cases: for example if you want to generate > multiple 256-bit symmetric keys (or other random data) at the same time, > each additional key after the first won't contain any additional entropy, > so if you break the state of the PRNG at the time the first one was > generated you get the others for free (until the thing reseeds). > > This design tradeoff is discussed in section 4.1 of the paper. Tweakable. > > That said, there is nothing to prevent the system admin > > from tweaking the Yarrow security parameters so that > > Yarrow will only spit out as many bits or pseudo-randomness > > as it gathers bits of entropy.[4] > > Well, I don't see a way to tune this without modifying the Yarrow design, > since the entropy pool is intentionally decoupled from the output > mechanism, and it seems like it would add additional (unnecessary) > overhead anyway to use it in that fashion. Look at the sysctls (some improvements and documentation coming). > Indications are we can probably get quite a lot of usable entropy from a > standard system (on the order of many kilobytes per second - but I need to > read more of the literature about processing of entropy samples) - in this > case I think maintaining a third pool which is directly tapped by > /dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to > go. I suspect you are missing the whole point of yarrow. Yarrow protects you from the compromises inherent in attackers injecting their own junk into the "third pool". 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