From owner-freebsd-security Wed May 3 14:32:16 2000 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id EE02C37B9DC for ; Wed, 3 May 2000 14:32:09 -0700 (PDT) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (unknown@analog20.sq.mntn.net [204.244.200.29]) by tusk.mountain-inter.net (8.10.0/8.10.0) with ESMTP id e43LW9n20183; Wed, 3 May 2000 14:32:10 -0700 Received: by grok.localnet (Postfix, from userid 1000) id A6837212E07; Wed, 3 May 2000 14:28:43 -0700 (PDT) Date: Wed, 3 May 2000 14:28:43 -0700 From: Steve Reid To: James Wyatt Cc: security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) Message-ID: <20000503142843.A411@grok.localnet> References: <200005031718.KAA63329@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from James Wyatt on Wed, May 03, 2000 at 01:06:04PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 03, 2000 at 01:06:04PM -0500, James Wyatt wrote: > How can you tell how much entropy is in the 'pool' for /dev/random and > it's about to start being not-so-random? Pull a sample once in a while and > Chi test it? I like being able to know. - Jy@ A Chi test won't work. As I understand it, the random device repeatedly uses MD5 over a pool of bits, which means the output will pass all of the usual statistical tests. I think (but am not sure) that the function is cryptographically strong. If it is then you should be "okay" as long as there was lots of entropy when you started. Since you're using 3DES you're already depending on cryptographic security; it's not like you're generating a "one time pad" for perfect security (/dev/random wouldn't suffice for that anyway because of the way it uses MD5). If you use /dev/random it will EOF when the "entropy counter" (a bogus concept but what can you do) reaches zero. This can be a VERY BAD THING(tm) if your application isn't expecting it because you may end up using only a partial key! Always check return values and handle them accordingly. You could just use /dev/urandom ("u" for "unlimited"?) which never EOFs and hope that the output is cryptographically strong enough. But check return values on IO calls anyway, just because it's a good idea. Most importantly, RTFM! `man 4 random` To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message