From owner-freebsd-current Thu Oct 26 13:48: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 1927037B479 for ; Thu, 26 Oct 2000 13:48:06 -0700 (PDT) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.9.3/8.9.3) with ESMTP id NAA20464 for ; Thu, 26 Oct 2000 13:50:46 -0700 Message-Id: <200010262050.NAA20464@screech.weirdnoise.com> X-Mailer: exmh version 2.0.3 To: current@FreeBSD.ORG In-Reply-To: Your message of "Thu, 26 Oct 2000 12:49:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Oct 2000 13:50:46 -0700 From: Ed Hall Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton wrote: : Pending Mark's approval, I'd like to suggest we add a cron job to : dump X k of data from /dev/random to a file (/boot/.periodic_entropy : maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at : boot, and only do the "long, annoying" failover process if neither file : exists. The only remaining questions would be how many k of data to dump : how often. How about skipping the "long, annoying failover process" altogether and simply logging to the console that the entropy reseeding process was incomplete? Forcing an indeterminate delay to gather entropy is more than a little paternalistic. I've little doubt of /dev/random's theoretical soundness. But a theoretical boost in security won't justify an actual reduction in availability to many folks. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message