From owner-freebsd-security  Thu Mar 27 11:42:38 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id LAA14120
          for security-outgoing; Thu, 27 Mar 1997 11:42:38 -0800 (PST)
Received: from grackle.grondar.za (grackle.grondar.za [196.7.18.131])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA14072;
          Thu, 27 Mar 1997 11:42:19 -0800 (PST)
Received: from grackle.grondar.za (localhost [127.0.0.1])
          by grackle.grondar.za (8.8.5/8.8.4) with ESMTP
	  id VAA07001; Thu, 27 Mar 1997 21:41:44 +0200 (SAT)
Message-Id: <199703271941.VAA07001@grackle.grondar.za>
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 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 27 Mar 1997 21:41:38 +0200
From: Mark Murray <mark@grondar.za>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote:
> 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. 
> I see blkdev randomness commented out in the code, maybe we can
> re-activate it?

I am very keen to vastly improve /dev/random.

I have lots of ideas, but my time supply and clue supply are not so good.

At the moment, the pool of randomness is stirred far too often by MD5. I
have some more recent code by Ted Ts'o which uses SHA, and is improved in
other ways.

I want to make a buffer (of structures (or whatever)) into which bits of
"harvested" entropy get thrown. Only when this entropy is required, will
the "stir" happen. I also want to include bits from the namei cache, and
from the network interfaces. I am dead-scared that I will slow down the
system, so I need to provide a "turn this feature off" knob for the speed
freaks.

> If my fears are true, we need to fix it ASAP.

Right now, I believe that the hard-earned randomness may be being used for
trivial jobs. I do believe, though, that much more entropy can be provided.

M
--
Mark Murray                PGP key fingerprint = 80 36 6E 40 83 D6 8A 36
This .sig is umop ap!sdn.                        BC 06 EA 0E 7A F2 CE CE