From owner-freebsd-security  Thu Mar 27 12:34:59 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA19374
          for security-outgoing; Thu, 27 Mar 1997 12:34:59 -0800 (PST)
Received: from smokey.systemics.com (leased-line.systemics.com [193.67.124.65])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA19368;
          Thu, 27 Mar 1997 12:34:46 -0800 (PST)
Received: from internal-mail.systemics.com (WrlJfwHuWfmbwwS7QPvrN2qTWUIxG8kH@internal-mail.systemics.com [193.67.124.74]) by smokey.systemics.com (8.6.12/8.6.12) with ESMTP id VAA03865; Thu, 27 Mar 1997 21:34:56 +0100
Received: from localhost (cc2tSQPlffHKRPNGwz97LKlhWcNtUBZg@localhost [127.0.0.1]) by internal-mail.systemics.com  with SMTPid VAA13075; Thu, 27 Mar 1997 21:34:44 +0100 (MET)
Message-Id: <199703272034.VAA13075@internal-mail.systemics.com>
X-Authentication-Warning: kampai.systemics.com: cc2tSQPlffHKRPNGwz97LKlhWcNtUBZg@localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 1.6.9 8/22/96
To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.ru>
cc: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, markm@freebsd.org,
        security@freebsd.org
Subject: Re: ATTENTION: Initial state of random pool 
In-reply-to: Your message of "Thu, 27 Mar 1997 22:17:56 +0300."
             <Pine.BSF.3.96.970327220407.872A-100000@nagual.ru> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 27 Mar 1997 21:34:43 +0100
From: Gary Howland <gary@systemics.com>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Recent Joerg report about fortune behaviour make me think about initial
> state of /dev/random, i.e. what happens when rndcontrol not called
> at all and no keys pressed (or the same key sequence, because it
> relays on scancode)? I fear that pool state is very predicted in this
> case. If I right, we need to do something to have true random in the
> pool even without rndcontrol tool (it called even after daemons
> started, so daemons can't use its advantages in any case!). I.e. add some
> timer randomness at the kernel boot state
> and allows rndcontrol-style IRQ set in kernel configure file. 

Ideally it should "throw in some randomness" from the previous session,
and not rely solely on the time.  For instance, if a block of data could
be "added" to the device at boot time, then it could still be useful for
daemons.  After booting is complete, then a new block of data could be
generated for the next reboot.

Comments?

Gary