Date: Sat, 22 Jul 2000 10:49:30 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: kris@FreeBSD.ORG (Kris Kennaway) Cc: mark@grondar.za (Mark Murray), jeroen@vangelderen.org (Jeroen C. van Gelderen), current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak Message-ID: <200007221749.KAA43756@gndrsh.dnsmgr.net> In-Reply-To: <Pine.BSF.4.21.0007211849570.68809-100000@freefall.freebsd.org> from Kris Kennaway at "Jul 21, 2000 06:54:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, 21 Jul 2000, Mark Murray wrote: > > > Section 2.1, last paragraph: > > "If a system is shut down, and restarted, it is desirable to store some > > high-entropy data (such as the key) in non-volatile memory. This allows > > the PRNG to be restarted in an unguessable state at the next restart. We > > call this data the reseed file." > > I'm all for storing a sample at shutdown and using it to help seed the > PRNG at startup, but it shouldn't be the only seed used (for example, the > case where the system has never been shut down (cleanly) before and so has > no pre-existing seed file is a BIG corner case to consider since thats how > the system is at the time it first generates SSH keys after a fresh > install). > > It might be only an academic vulnerability, but if someone can read your > HD during the time the system is shut down then I'd prefer them not to > know the precise state when the system next starts up again. Yes, if they > can read they can probably also write, but it seems like a mistake when > there's nothing really gained by saving the complete state, as opposed to > an extract. And for folks like us who do mass installs via dd if=/dev/da1 of=/dev/da2, where da1 is a mastered image created via ``make installworld DESTDIR=/mnt'', the corner case is very large. I have been bitten by an event where the master disk was booted once before replication, and thus all systems had _IDENTICAL_ /etc/ssh contents. Not a very good idea !! We have amended the manufacturing process now, so that part of the disk replication is the nuking and regeneration of /etc/ssh. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007221749.KAA43756>