Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jan 2001 08:43:51 +0200
From:      Mark Murray <mark@grondar.za>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Warner Losh <imp@harmony.village.org>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, Sheldon Hearn <sheldonh@uunet.co.za>, obrien@FreeBSD.org, Doug Barton <dougb@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh 
Message-ID:  <200101120644.f0C6hvI12630@gratis.grondar.za>
In-Reply-To: <200101120534.f0C5YYH96390@earth.backplane.com> ; from Matt Dillon <dillon@earth.backplane.com>  "Thu, 11 Jan 2001 21:34:34 PST."
References:  <200101120534.f0C5YYH96390@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>     I would do the following:
> 
> 	* Use Warner's fix, possibly adding 'dmesg' output in phase-1.

It make more sense to make the random device nonblocking-at-boot than
to do this.

> 	* Change the crontab to something reasonable, like once every
> 	  30 minutes.  Every 3 minutes is way too disruptive.  Massive
> 	  overkill.

Read the Yarrow paper. Yarrow suggests an entropy dump _every_ reseed.
Best let the user/admin tweek it as required. "crontab -e" is your
friend.

> 	* Change the rc.conf variable to default to /var/db/entropy.data
> 	  (or whatever filename, as long as it is in /var/db).

1st point + 3rd point == "hack upon a hack". The 1st hack is to negate
the block-at boot which was specifically added for security reasons.
The /var/db thing then becomes possible because the code to achive the
mount is asking for cryptographic randomness. (which was killed by the
the first hack).

Do we really need cryptographic randomness to do a "fsck -y" and
"mount -a"? If not, then that is the problem.

Breaking the RNG with a couple of really silly rc hacks (instead of
just taking away the block-at-boot) is not a bright suggestion.

Remember that the block-at-boot is to prevent sshd from making crappy
keys as well.

M
-- 
Mark Murray
Warning: this .sig is umop ap!sdn


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101120644.f0C6hvI12630>