From owner-freebsd-current Thu Oct 26 14: 1:22 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 2616837B4D7 for ; Thu, 26 Oct 2000 14:01:19 -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 OAA20560; Thu, 26 Oct 2000 14:04:02 -0700 Message-Id: <200010262104.OAA20560@screech.weirdnoise.com> X-Mailer: exmh version 2.0.3 To: Doug Barton Cc: current@FreeBSD.ORG Subject: Re: entropy reseeding is totally broken 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 14:04:02 -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