Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 19 Aug 2002 11:07:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 19 Aug 2002 11:07:09 -0400 Received: from Morgoth.esiway.net ([193.194.16.157]:774 "EHLO Morgoth.esiway.net") by vger.kernel.org with ESMTP id ; Mon, 19 Aug 2002 11:07:08 -0400 Date: Mon, 19 Aug 2002 17:11:03 +0200 (CEST) From: Marco Colombo To: Oliver Xymoron cc: Marco Colombo , Andreas Dilger , Subject: Re: Problem with random.c and PPC In-Reply-To: <20020819140207.GC14427@waste.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2160 Lines: 51 On Mon, 19 Aug 2002, Oliver Xymoron wrote: > > If you need a weak solution (a perturbated PRNG), just read a few bits > > from /dev/random at times (but in a controlled and defined way). > > It might be helpful to think of /dev/urandom as akin to /dev/random with > O_NONBLOCK. "Give me stronger bits if you got 'em" is desirable, > otherwise this thread would be much shorter. "desirable", yes, I see... B-). But I have to understand why, yet. "Give me the best you can, but even 0 is ok" just serves to help people waste resources. If your application is fine with (potentially) guessable bits, you don't need /dev/random at all. If you do care about a minimum, you know it in advance, so do fetch those bits (and only them) from /dev/random, and use them. Yes, it may block, but that's life. Resources aren't infinite. I haven't seen the code, but I guess most programs don't even use */dev/random* output correctly. If you read 512 bits from it, you only get 512 of the kernel 'best effort' for random bits. Using those 512 to produce a 512 bits long key it as optimistic as saying: "the kernel is a (mathematically) perfect source of random bits". You'd better scramble them to produce a 256 or 128 or 64 bits key and hope for the best. (yes it drains away entropy bits even faster, and yes that's being paranoid) If you ride Linus' "we're living in a pratical world" horse, and say: the application can't block, so let's use /dev/urandom, then a good PRNG (+ all the crypto hiding you need) fits as well. And don't see anything "sad" about it. I'm missing any real argument for having /dev/urandom logic into the kernel. As regards /dev/random being as strong (and paranoid) as possible, I'm 101% with you. .TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/