From owner-freebsd-current Mon Oct 30 10:24: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 98E8937B479 for ; Mon, 30 Oct 2000 10:24:00 -0800 (PST) Received: (qmail 27765 invoked by uid 100); 30 Oct 2000 18:23:51 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.48311.525835.795821@guru.mired.org> Date: Mon, 30 Oct 2000 12:23:51 -0600 (CST) To: current@freebsd.org Subject: /dev/random thoughts X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Like everyone else, I've been bit by /dev/random blocking because it didn't have enough entropy. I recently got bit after booting the system single-user to do some work, meaning nothing in the discussion about when/where/how to deal with the entropy information addressed this one. It seems like we're being a bit paranoid about things - arguments about that not being possible notwithstanding. I mean - if I mount a few dozen file systems using inode numbers drawn from a PRNG instead of being cryptographic quality, then *quit using the PRNG*, how much extra exposure do I have? It's clear to me it would be less painful if we had two bike sheds - uh, behaviors for /dev/random. One would be active at system boot time, and hence while the system was running single user. It wouldn't require lots of entropy, and also wouldn't be of cryptographic quality (though that would be nice)u. The other would be the quality system being built, but would be enabled by some userland action. Once enabled it can't be turned off. The obvious userland action is writing to /dev/random to give it entropy. However, someone who actually understands the issues should go through the rc sequence and figure out when we need cryptographic quality randomness (or we could add a "CRYPTORANDOM" to the NetBSD-like RC, and things that require that can be flagged as such). This is the step needed to decide if doing this kind of split has any advantage at all. The one problem I see is preventing someone from shotting themselves in the foot by, for instance, creating ssh host keys using the low-quality /dev/random. There are certainly others. Just some thoughts, possibly useful, probably not - but I thought worth sharing.